DesktopNaotu: an offline desktop build of Baidu Mind Map

What DesktopNaotu is, and the problem it removes

Baidu Mind Map is a web editor. You open it in a browser, the document lives on Baidu's servers, and the editor itself is fetched over the network every time. DesktopNaotu takes that same editor and wraps it in an Electron shell so the whole thing runs from a local install. The README describes it plainly: "a localized version of Baidu Mind Mapping, which helps you to use Mind Mapping Tool without Internet."

The audience is narrow and specific. People who work on machines that are not allowed to reach the public internet, or who simply do not want a mind map sitting on someone else's server. The feature list is built around that: local .km file operations, drag-and-drop opening of .km files, file association so double-clicking a .km opens the app, and automatic saving. There is no account, no sync, no collaboration layer mentioned anywhere in the README. That absence is the product.

The project is written in TypeScript and released under GPL-2.0. The repository has been pushed to as recently as 2026-09-01, but the newest release listed is v3.2.3 from 2019-04-17, and package.json still declares version 3.2.3. So the code sees occasional movement while the shipped artifacts have not changed in years. Treat the release page, not the commit graph, as what you actually get.

How the Electron shell and .km files fit together

The architecture visible in the repository is a two-part split. The root holds build configuration (gulpfile.js, bower.json, tsconfig.json, config.json) and the app/ directory holds the Electron application, with dist/main.js named as the entry point in package.json. The mind map editor itself is the Baidu front-end, pulled in through bower rather than npm, which is why the install steps require both package managers.

The data model is the .km file. Everything the README promises about persistence is phrased in terms of that format: opening it, dragging it in, associating it with the app, saving it automatically. There is no mention of an export to another mind map format, no import from one, and no schema documentation in the README. If you need to move maps between DesktopNaotu and another tool, the README does not describe a supported path. The wiki is linked for downloading Baidu Mind Map files and ProcessOn files in the Chinese section, but that is a separate document-fetching procedure, not a converter built into the app.

Because the editor is a local copy of a web application, the runtime is heavier than the file size suggests. The release table lists most builds at under 50 MB, with the Windows XP mini build under 8 MB. That mini build is the one exception the README calls out explicitly: it does not support debugging. The others are described as supporting all functions.

Installing DesktopNaotu and opening your first .km file

For normal use you do not build anything. The README gives two download routes: Baidu Cloud, or the GitHub Releases page. Pick the asset matching your platform from the table. macOS 64-bit, Linux 64-bit, Windows 7/10 in both 64-bit and 32-bit, and a separate Windows XP 32-bit mini build. The README does not document a package manager install, so there is no brew, apt or winget command to give here.

Once the app is running, the documented workflow is file-based. Drag a .km file onto the window, or associate the extension so a double-click opens it. Auto-save then handles persistence. The README does not state where auto-save writes, whether it keeps a backup, or what happens if two copies of the same file are open, so confirm the save path yourself before trusting it with a map you care about.

If you want to build from source instead, the README's steps are explicit about the order and about two version pins that exist to work around Node compatibility problems. First the global tools and dependencies:

npm install -g gulp
npm install -g bower

npm install
bower install

On Node v10.x or newer the README says to replace graceful-fs, because the old version breaks. It also gives a fallback if the primordials error persists:

npm install graceful-fs
rm -rf node_modules/[email protected]@graceful-fs

And it pins the type definitions to a specific major line:

npm install @types/[email protected]

Then the build and a test run:

gulp
npm run demo

The demo script is electron ., so a window should appear running the editor from source. The README's own packaging scripts, such as packwin64 and packmacos, call electron-packager with electron-version=3.1.13, which tells you the runtime the maintainers target. That is a very old Electron major, and it is the single biggest reason to prefer prebuilt binaries over a self-built one.

Where DesktopNaotu is the wrong choice

The release cadence is the first problem. The latest release is v3.2.3 from 2019-04-17. The repository has been pushed to since then, but no newer release is listed. Anyone evaluating this as a long-term document store should weigh that: the app you download today is the app from 2019.

The build chain is the second. It needs gulp and bower, bower is a package manager the wider JavaScript ecosystem has largely moved away from, and the README itself documents patching around graceful-fs and pinning @types/node to 12.x. Those instructions are not optional polish. They are the maintainers telling you the default dependency resolution does not work on current Node. Building from source is a repair job, not a build.

The third is scope. This is a single-user, single-machine editor. The README lists no sync, no sharing, no multi-device story, and no collaboration. If two people need to work on the same map, the app gives you a file and nothing else. It is also the wrong tool if you need your maps in a format other tools can read, because the README only ever talks about .km and does not describe a converter.

Finally, the README opens with a recommendation for the author's other project, MindMap MT, described as replacing XMind and MindMaster for an internal team. That is worth reading as a signal about where the author's attention sits.

DesktopNaotu versus a web-based mind map tool

The obvious alternative class is the browser-based editor it is derived from, plus the hosted tools people usually compare it against. The difference is not the feature list, since DesktopNaotu inherits the Baidu editor's basic functions. The difference is where the document lives and what happens when the network is gone.

A hosted tool keeps the document on a server and gives you a share link, which is exactly what you want if collaboration matters. DesktopNaotu keeps the document in a file on your disk and gives you nothing else. That is a real trade, not a strict upgrade. You lose sharing and gain the ability to open a map on a laptop with the Wi-Fi off.

The second alternative is a native mind map application with a longer release history and a documented interchange format. Those typically ship newer runtimes and support export to formats other editors read. DesktopNaotu's advantage over them is narrower: it is free, it is GPL-2.0, and the README's Windows XP mini build under 8 MB is evidence of a deliberate effort to run on hardware that modern Electron apps have abandoned. If your constraint is an old machine or an offline one, that matters more than release cadence.

Licence, maintenance and what a fork costs you

The code is released under GPL-2.0, stated in the README and present as a LICENSE file at the repository root. The practical consequence, without giving legal advice: if you distribute a modified build, the GPL's source-availability terms travel with it. Internal use is a different question from redistribution, and the licence text, not this article, is what governs it.

Upgrade cost is dominated by the Electron version. The packaging scripts pin electron-version=3.1.13, and the build instructions pin @types/node to 12.x and require a graceful-fs replacement. Moving this to a current Electron major is not a version bump; it is a migration through several years of breaking changes in the runtime and in the surrounding build tooling. The README does not document a rollback procedure for a failed upgrade, and it does not describe a supported upgrade path at all.

For a user, the upgrade cost is close to zero, because there is nothing to upgrade to. You install the release asset and that is the end of the maintenance story. For a forker, the cost is the opposite: you inherit a bower-based front-end, a gulp build, and an Electron runtime old enough that its own security posture is a separate question the README does not address.

Editorial conclusion

Adopt DesktopNaotu if you need a mind map editor that runs without a network connection and stores everything in local .km files, and if you are willing to either use the prebuilt binaries or fight a gulp and bower build chain. Do not adopt it if you need a maintained editor with frequent releases, a modern plugin ecosystem, or a documented data format beyond the .km file. Before committing, verify three things: that the release asset matching your OS and architecture actually launches, that dragging a .km file onto the window opens it and that auto-save writes back to the same path, and that the GPL-2.0 licence is compatible with how you plan to redistribute anything you build from the source.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. NaoTu/DesktopNaotu on GitHub
4. README
5. Releases