Open Enterprise Solutions (OES)

OES is a source-available platform for building line-of-business applications — stock, accounting,
payroll, sales, whatever a business keeps books on — written in C++20. You describe the business
in metadata (catalogs, documents, registers, charts of accounts and of calculation types), write
its rules in a built-in scripting language, and read its data with a query language and a report
composer. The platform turns the description into database tables, forms and reports, and keeps
the database in step with the description as it changes.

It ships with everything that loop needs: a designer, a compiler and bytecode interpreter, a remote
debugger, a multi-database layer, a job manager, an application server, a cluster that gives each base
a server process of its own, a thin client and a web server — and a built-in MCP server, so an
AI assistant can read, build and check a configuration alongside the developer, through the same
doors the developer uses.

Status: 2.0.0-preview.1 — the first release after the alpha, on the
road to beta: the database format may still change, and nothing migrates from 1.x.

Try it

1. Download the latest release:
   Windows x64 (.zip), Linux x64 (.tar.gz) or macOS arm64 (.dmg, unsigned — the
   installation page says how to open it).
2. Unpack it and run launcher: Add a base, choose File (local database), then press Designer.
3. Follow First steps: a small stock
   application, built in about fifteen minutes.

Building from source is under Quick Start.

New here? The wiki is the
user's guide: installing a build, a first application step by step, the designer, the metadata
tree, forms, the language, queries and reports, and the pitfalls.

What you build with it

Key features

• Query language — SELECT over the business objects and over the registers' virtual tables
  (Balance, Turnovers, BalanceAndTurnovers, SliceLast / SliceFirst, DrCrTurnovers,
  RecordsWithAccountDimensions, ActualActionPeriod, ScheduleData, Recalculation); nested queries, temporary
  tables and query packages, TOTALS BY … HIERARCHY, CAST, VALUE, parameters that keep their
  type. A query runs as SQL on the server wherever the engine can prove it may, and in memory
  otherwise — with the same answer.
• Report composer — groupings, totals, cross tables, drill-down from a cell to the records
  behind it, parameters, and the user's own saved settings and variants. Output
  to a spreadsheet document that prints, and exports to Excel (.xlsx, read and write) and
  Word (.docx, write).
• Scripting language — two dialects over one compiler (CES, C-flavoured, the default; VES,
  keyword-fenced), procedures and functions, lambdas with closure capture, try … except,
  multi-line strings for query texts, LINQ (from … where … join … group by … orderby … select)
  compiled into the bytecode, 94 built-in functions and 7 procedures. Bytecode of 81 opcodes, kept
  in an ahead-of-time cache so a module compiles once per configuration version and engine.
• Designer — metadata tree, form designer (drag a field onto a form and a bound control
  appears), code editor with IntelliSense, a query constructor that edits the query inside the
  literal the caret is in, a spreadsheet template editor, configuration compare, and a git panel.
  Every property carries its own help text.
• Debugger — remote, over a WebSocket (ports 7700–7709): breakpoints with conditions, stepping, watches,
  evaluation in the stopped frame; the designer attaches to a client on a file base, to a thin
  client's session on its server, or to the web runtime.
• Access control — rights per object and operation, folded across a user's roles. A role either
  permits (adds rights) or restricts (subtracts them, whatever the others grant), so a data
  separator is declared once instead of copied into every role. Row-level security is code in the
  role (OnAccessRead / OnAccessWrite) that narrows what a query may read or write — fail-closed.
• Schema management — the configuration is applied to the database by a diff; a rehearsal shows
  the exact DDL before anything moves; on Firebird a two-phase apply compensates its first commit if
  the second fails, so a refused apply leaves the database where it was.
• Jobs — scheduled and background jobs in sessions of their own, with a cross-process claim so a
  job runs once across a cluster; the platform's own housekeeping (totals folding and verification,
  Firebird sweep and backup) runs on the same manager.
• AI access over MCP — an MCP server inside the designer (and per base on the application server), 113 tools across the platform: read and
  edit metadata and modules; apply the configuration with a rehearsal; run code on the
  application; ask the data questions and compose reports; drive the debugger; read and write the
  registration journal. Protected by a token, listening on loopback by default; every call is
  journalled.
• Application server — appserver serves the bases its server.conf lists from one process:
  Firebird and PostgreSQL side by side, one worker pool for all, and each base with its own
  connections, sessions, locks, jobs and journal. Several servers may share a base; a desktop client
  and a server may not use one at the same time. Passwords in its configuration are sealed
  (AES-256-GCM).
• Application cluster — appcluster runs the same server folder as a server process per base and
  holds the clients' port in front of them: a base whose process falls takes only its own clients with
  it and is started again; the other bases do not notice. A console program or a service of the system
  (appcluster --install on Windows, a systemd unit on Linux). appcluster-tray shows each base's
  server and starts, stops and restarts it — and starts the cluster itself when none runs.
• Thin client — enterprise-thin runs no code of the configuration: the server holds the session,
  its forms and documents, the client draws what it is answered and sends what the person did. One
  client protocol — binary OES-RPC packets over WebSocket, or JSON-RPC
  over HTTP, to an application server; a file base is the same protocol in the client's own process. The
  designer, designer-thin, works on the same protocol. See thin-client.md.
• Databases — Firebird (embedded, shipped with the distribution) and PostgreSQL for production;
  ODBC; SQLite for tests and logging.
• Localisation — the whole interface in English, Russian and Ukrainian; every caption of a
  configuration can be written per language.
• Web client — in progress. webserver serves the same forms to a browser: it carries it to a
  file base or to an application server's base over the client protocol, with TLS. List and
  document forms draw today, on a desktop and on a phone; the rest of the controls are arriving.

Measured

On a copy of a 40 000-employee payroll base (Release, x86): a month's payroll reposted in about
20 s, the payroll sheet report built in about 4 s.

Screenshots

Quick Start

Windows

1. Install Visual Studio 2022 with the Desktop development with C++ workload
   (the projects use its toolset, v143). CMake is not needed for the MSBuild build.
2. Clone the repository and initialise the submodules:

   git clone https://github.com/open-enterprise-solutions/enterprise.git
   cd enterprise
   git submodule update --init --recursive
   

3. Open enterprise.sln in Visual Studio.
4. Select configuration Debug|Win32 or Release|x64.
5. Build the solution (Ctrl+Shift+B). Binaries are placed in bin\<Platform>\<Configuration>\
   (Win32 or Win64).
6. Run designer-thin.exe to build a configuration, enterprise-thin.exe to work in it — or
   launcher.exe to pick a base first (it starts the same two programs). appserver.exe serves the bases of a server folder with no
   window, appcluster.exe the same folder with a process per base (appcluster-tray.exe shows and
   steers it); both clients work in a base they serve, or in a file base.

macOS

The CMake build lives at CMakeLists.txt (repo root, CMake ≥ 3.20).

# Install dependencies (wxWidgets is built from its submodule)
brew install cmake ninja

# Clone and initialise submodules
git clone https://github.com/open-enterprise-solutions/enterprise.git
cd enterprise
git submodule update --init --recursive

# Configure and build
cmake --preset macos-release -DOES_USE_FIREBIRD=ON -DOES_USE_POSTGRESQL=ON
cmake --build --preset macos-release

Linux (Ubuntu / Debian)

The CMake build lives at CMakeLists.txt (repo root, CMake ≥ 3.20).

# Install dependencies (wxWidgets is built from its submodule)
sudo apt update
sudo apt install -y build-essential cmake ninja-build pkg-config \
    libgtk-3-dev libsqlite3-dev uuid-dev libpq-dev

# Clone and initialise submodules
git clone https://github.com/open-enterprise-solutions/enterprise.git
cd enterprise
git submodule update --init --recursive

# Configure and build
cmake --preset linux-release -DOES_USE_FIREBIRD=ON -DOES_USE_POSTGRESQL=ON
cmake --build --preset linux-release

Build Instructions

Windows — MSBuild

# From a Developer Command Prompt for VS
msbuild enterprise.sln /p:Configuration=Release /p:Platform=x64 /m

Output: bin\Win64\Release\

All Platforms — CMake

The top-level CMakeLists.txt (CMake ≥ 3.20) builds every target. DB drivers opt in — OES_USE_FIREBIRD, OES_USE_POSTGRESQL, OES_USE_ODBC (all default OFF); SQLite is always embedded, no flag:

cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --parallel

wxWidgets is built from its submodule as part of the tree; nothing has to be installed for it.

The unit tests (Google Test) build with the same tree: -DBUILD_TESTING=ON.

wxWidgets Submodule

wxWidgets 3.3.4 lives at src/3rdparty/wxWidgets as a git submodule. After cloning:

git submodule update --init --recursive

Project Structure

enterprise/
├── enterprise.sln            # MSBuild solution (18 projects, Mbed TLS, llhttp and LodePNG among them)
├── CMakeLists.txt            # the cross-platform build, tests included
├── Common.props              # Shared MSBuild properties (paths, platforms)
├── ConfigurationDefs.props   # Preprocessor definitions per configuration
├── LICENSE.md                # PolyForm Noncommercial 1.0.0 (source-available)
├── NOTICE.md                 # third-party licenses, the wx fork
├── lang/                     # interface translations: the template, and per language (ru, uk) the .po and its .mo
├── tests/                    # Google Test suites (built by CMake)
├── docs/                     # how we work, build, portability, architecture — start with docs/README.md
│   └── private/              # PRIVATE submodule (design docs) — resolves for members of the
│                             # organisation only and is empty for everyone else. The build never
│                             # needs it, so links to docs/private/… will not open for you.
└── src/
    ├── 3rdparty/             # Git submodules: wxWidgets 3.3.4, Mbed TLS, Asio, llhttp, LodePNG, NanoSVG, cpp-httplib, nlohmann/json
    └── engine/
        ├── core/             # What the engine and its clients share: values, strings, dates, nodes, the journal
        ├── backend/          # Core engine DLL
        │   ├── compiler/     # Lexer, parser, bytecode, interpreter, LINQ
        │   ├── query/        # The query language: parse, lower, render to SQL, run in memory
        │   ├── composition/  # The report composer
        │   ├── calculation/  # The calculation register's engine (displacement, base, recalculation)
        │   ├── databaseLayer/# DB abstraction + drivers (Firebird, PostgreSQL, SQLite, ODBC)
        │   ├── metaCollection/  # Metadata: business objects, registers, charts, common objects
        │   ├── mcp/          # The MCP server and its tools
        │   ├── job/          # Scheduled and background jobs
        │   ├── session/      # Sessions, their registry and worker pools
        │   ├── lock/         # Record locks, cluster-wide
        │   ├── sheetFormat/  # Spreadsheet import and export (.xlsx, .docx)
        │   ├── debugger/     # Debug server/client (WebSocket)
        │   ├── moduleManager/
        │   ├── propertyManager/
        │   └── system/       # Built-in functions and values
        ├── protocol/         # The client protocol: its contract (protocol.h) and connections
        ├── frmserver/        # The server side of the thin client: sessions, forms, the client host
        ├── frmclient/        # The thin client's window, document/view and controls
        ├── fileserver/       # A file base in the thin client's process
        ├── enterprise-thin/  # The thin client runtime executable
        ├── designer-thin/    # The thin designer executable
        ├── webserver/        # The bases' transport for browsers and the browser client (www/); links protocol + core
        ├── launcher/         # Launcher (connection chooser)
        ├── appserver/        # The application server
        ├── appcluster/       # The application cluster: a server process per base, the port, restarts; a service
        ├── appcluster-tray/  # The cluster's tray: its servers and their verbs, starting the cluster
        ├── codeRunner/       # Script runner (its own code editor, no document behind it)
        └── simplePlugin/     # Example plugin

Technology Stack

Contributing

Contributions are welcome — see CONTRIBUTING.md for what a change should
look like and, more importantly, for what sending one means.

The short version: branch from develop and pull-request into it; match the code around you;
say why in the commit message, because the diff already says what. And because this
project is licensed commercially as well as noncommercially, opening a pull request includes a
grant that lets us sublicense your contribution — you keep your copyright, we get the right to
sell what contains it. That paragraph is the one worth reading in full before you send
anything.

Bug reports and feature requests are welcome as GitHub Issues.

License

OES is source-available, not open source, under the
PolyForm Noncommercial License 1.0.0. Copyright is held by Maksym Korniienko,
acting as Open Enterprise Solutions until it is registered as a company (NOTICE.md).

Free, and meant to be used: clone it, build it, break it, change it, run it on your own
machine, write configurations for it, teach a course from it, write a thesis about it, publish
what you learned. No notification, no permission, no explanation owed to anyone.

Also free: evaluation, for a business too. A company or an implementer may install it and
run it to decide whether to build on it — trial configurations, test data, its own people.
Live work is not evaluation.

Needs a license from us: earning from it. Running it in a business, providing a service
with it, shipping it inside something you are paid for — and, said outright because it is what
these sources are most likely to be taken for, forking it to ship a rival platform or lifting a
piece of it (the query engine, the composition and reporting engine, the metadata layer) into a
product of your own.

A commercial license is for a build we release — we answer for it, and it carries the
license check. The platform as you build it yourself may be used for noncommercial and
evaluation purposes: to study it, or to decide whether to use it, for example.

Under your own brand — an implementer that takes the platform to its customers under its
own name, builds it itself and licenses it to them on its own terms — the platform is licensed
separately, case by case. It stays ours all the same: we develop it and release its patches,
and the implementer decides whether and when to take them. Its own features on top — what it
sells besides the brand — are its own, because it wrote them. We own the land; what you cook
on it is yours.

What the terms above do not cover is in NOTICE.md: third-party components keep
their own licenses, and the wxWidgets-derived widget sources remain under the wxWindows
Library Licence.