O2OA: a Java low-code OA platform with a Chinese enterprise stack

What O2OA actually is, and who it is built for

O2OA, also written 翱途, is a low-code development platform for office automation and collaborative work. The README describes it as a 100% open source enterprise collaboration customization platform that provides complete front and back end APIs plus module customization. The pieces it advertises are a process engine, form customization, page customization and business data services, with cross-platform mobile office support. The primary language in the repository is JavaScript, but the server side is JavaEE and the badge in the README names JDK 11.

The intended audience is not a Western SaaS team. The README lists support for domestic Chinese operating systems such as UOS and Kylin, and for domestic databases including Dameng and Kingbase, and it says the platform holds a domestic Xinchuang certification. It also names government OA and military informatization as use cases. That tells you where the product is aimed: organisations that must run on an approved domestic stack. If you are outside that context, the value proposition is weaker, because the parts that make O2OA interesting are the parts tied to that ecosystem.

How the platform is put together

The repository is a monorepo with four visible product directories: o2server, o2web, o2android and o2ios. That layout maps directly onto the architecture. o2server holds the JavaEE server, o2web holds the browser client, and the two mobile directories hold the native apps. The root package.json version is 4.0.3763, and its scripts drive the build through gulp and Maven.

The build scripts are the clearest statement of how the pieces fit. build_server_script changes into o2server and runs mvn clean followed by mvn install, so the server is a Maven project. build_web is a gulp task, so the web client is a separate gulp-built asset tree. build_parallel chains build_server, build_web and build_api, which means the API documentation is generated as its own artifact rather than being written by hand. There is also a build_api_version script that invokes jsdoc with a version parameter, confirming that the published API reference is extracted from source.

The deployment scripts are more interesting than the build scripts. There is a separate preparation and deploy target for each platform: windows_java11, linux_java11, aix_java11, arm_java11, macosx64_java11, macosarm_java11, mips_java11, raspi_java11 and sw_java11. Each target selects a Java 11 runtime for that architecture. That is why the README can promise AIX, Raspberry Pi, ARM Linux and MIPS Linux alongside the usual three operating systems. The cost of that breadth is that you are shipping a JVM per platform rather than relying on whatever runtime the host already has.

Installing O2OA from the release package on Linux

The README does not walk through a source build for end users. It points at two deployment tutorials on the vendor site, one for Windows and one for Linux, and at a separate source compilation tutorial. What the README does give is a start procedure for the packaged server. The package name follows the pattern o2server.yyyyMMddHHmmss_linux.zip, and the README says to open ports 80, 20020 and 20030 before starting.

After unzipping the package and changing into the extracted directory, you enter the o2server subdirectory and run the start script:

cd o2server
yyyyMMddHHmmss_linux
cd o2server
./start_linux.sh

The README states that the server console starts and that related services complete automatically. Once they finish, the README says to open a browser at http://127.0.0.1. The Windows path is the same shape: unzip o2server.yyyyMMddHHmmss_windows.zip, confirm the same three ports, open the o2server folder and double-click start_windows.bat. The README also links a source compilation tutorial, and the root package.json exposes preparation and build steps such as preperation:linux, but the README directs readers to that online tutorial for the source route rather than documenting it inline.

The H2 database is a demo default, not a production choice

The README is unusually direct about this. It states that the bundled H2 database is an embedded in-memory database, suited to development and demonstration environments, and not suited to production. It recommends commercial-grade databases instead, naming MySQL 8, Oracle 12C and SQL Server 2012. It also says O2OA provides scheduled backup and recovery and advises enabling scheduled backups in production so data can be restored if the database fails.

This is the single most important operational fact about the project, and it is easy to miss because the packaged server starts and serves a working UI with no database configuration at all. A team that deploys the zip, sees the login page, and moves on has a system whose data lives in a process-local store. The README's own recommendation is the fix: point O2OA at MySQL 8 or another supported database before anyone puts real records in it. Note also that the README gives the database names but does not show the connection configuration, so the actual datasource settings have to come from the deployment tutorial or the server configuration files.

Licence terms decide whether you can ship this

O2OA is licensed under AGPL-3.0. The README then states the vendor's own interpretation of when that is a problem. Learning and researching O2OA, or building an internal office system on the platform without distributing a closed-source version and without using it in a commercial project, is described as not creating infringement risk. Reselling it, distributing a closed-source version, or using it as part of a commercial project is described as requiring a commercial licence purchased from Land Network, with a link to their commercial licensing and support page.

That is a vendor statement, not legal advice, and the distinction it draws between internal use and commercial use is narrower than what AGPL-3.0 itself says. AGPL-3.0's network clause triggers on providing the software's functionality to users over a network, which is exactly what an internal OA deployment does. If your organisation has a legal function, have them read the licence and the vendor's page together before the first production deployment. The practical point is that O2OA is open source in the sense that the source is published, and commercial in the sense that the vendor expects payment for several common deployment patterns.

Where O2OA is the wrong tool

The documentation is in Chinese. The README, the handbook link, the deployment tutorials and the forum are all Chinese-language resources, and the repository does not present an English manual. An engineering team that cannot read Chinese will be working from the source and the API reference alone, which is a real cost on a platform this size.

The second constraint is the stack. O2OA is a JavaEE server with a gulp-built web client and separate native Android and iOS clients. If your organisation has standardised on a Node or Python service stack and wants a workflow engine it can embed as a library, O2OA is the wrong shape: it is an application platform you deploy and customize, not a component you import. The mobile story is also native apps rather than a responsive web client, so customizing the mobile experience means touching o2android or o2ios.

Finally, the repository does not surface a versioned release list, and the README publishes no release notes or upgrade procedure. Anyone who needs predictable upgrade windows and a documented changelog should confirm how the vendor handles that before standardising on the platform.

How O2OA differs from a general-purpose BPM engine

The obvious alternative for a Java team that mainly wants workflow is a standalone BPM engine such as Camunda or Flowable, embedded in your own application. The difference in approach is fundamental. A BPM engine gives you a process definition format, an execution engine and an API, and leaves the user interface, the form builder, the identity model and the deployment packaging to you. O2OA gives you the whole application: process engine plus form customization plus page customization plus a web client plus mobile clients, delivered as a server package you start with a shell script.

That trade is the reason to pick one or the other. With an embedded engine you keep full control of the codebase and the licence surface, and you pay for it by building the OA layer yourself. With O2OA you get an OA product on day one, and you accept its architecture, its Chinese documentation and its AGPL-3.0 terms. There is a middle option worth noting: because O2OA exposes complete front and back end APIs and supports white-label secondary development, a team could treat it as a platform and build only the custom modules, rather than forking the core.

Editorial conclusion

Adopt O2OA if you run a Chinese enterprise or government environment that needs an OA and workflow platform on Java, and if you are comfortable with AGPL-3.0 or willing to buy a commercial licence. Do not adopt it if your team cannot read Chinese documentation or if you intend to resell a closed-source derivative. Before committing, verify three things: that a supported commercial database such as MySQL 8 is in place instead of the bundled H2 database, that the ports 80, 20020 and 20030 are open, and that your legal position on redistribution is settled with Land Network.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. o2oa/o2oa on GitHub
4. Project website
5. README