What Is OpenHarmony? — Sorting Out How It Differs from HarmonyOS and HarmonyOS NEXT

“Are OpenHarmony and HarmonyOS the same thing?” “Do Android apps run on HarmonyOS NEXT?” These two questions have to be kept apart.

OpenHarmony is an open source OS project; HarmonyOS is Huawei’s commercial OS product. HarmonyOS NEXT is the name for the generation in which that commercial OS dropped Android compatibility. Separate the project from the product first, then establish which generation of the product is meant, and the three similar-sounding names fall into place.

Japanese-language material tends to blur these together, and misconceptions such as “Hongmeng = the Chinese version of Android” or “install OpenHarmony and HarmonyOS apps will run” have taken hold. From the position of someone deciding which OS to put into a device, that confusion does real damage. What you need to ask your suppliers, which licenses your legal team cares about, which language your developers have to learn — all of it changes depending on which one you mean.

This article is aimed at engineers working on embedded equipment and business systems, and it sorts out the relationship between OpenHarmony, HarmonyOS and HarmonyOS NEXT on the basis of primary sources: the official OpenHarmony documentation and Huawei’s official announcements. The practical judgment of whether it is a viable option to put into a device is covered in the companion article, Is OpenHarmony a Viable OS for Industrial Equipment?.

This article organizes the information as it stood in July 2026. Read the figures, version tables and maintenance schedules below as statements about that point in time. The generation names in particular (NEXT / 5 / 6 / 7), the regional rollout of smartphones and the app market, and the community’s branch maintenance schedule are fast-moving areas. Before you use any of this for a procurement or design decision, open the sources listed in each section’s footnotes and check their dates.

1. The Conclusion First

OpenHarmony and HarmonyOS differ both in how much is published and in what you need in order to use them. OpenHarmony is a project incubated and operated by the OpenAtom Foundation, and anyone can obtain the source. HarmonyOS is a commercial product that puts Huawei’s own frameworks, app distribution platform and cloud services on top of that foundation, and its source is not published in full.¹²

When you talk about HarmonyOS, name the generation as well. The 2 to 4.x generations rolled out on smartphones combine AOSP (Android Open Source Project) with OpenHarmony. Keep them separate from NEXT (= HarmonyOS 5) onward, which dropped Android compatibility. 1.0 is an earlier generation, aimed at smart screens. And even where the app model has elements in common, there is no guarantee that a HarmonyOS app will run as-is on an OpenHarmony device (Sections 4 and 5).³⁴

When adopting it for a device, check the configuration and the maintenance rather than the name. Which of the three system types you use, who writes the apps, who maintains it for as long as you need it, and whose component licenses you have to comply with are what the decision rests on. Eclipse Oniro, the European lineage, is also treated as a separate line (Sections 3, 5 and 7 to 9).

Reading Paths by Purpose

If you only need to know the differences, Sections 2, 4 and 5 are enough; if you are considering adopting it for a device, go on through Sections 3 and 6 to 8. The concrete adoption decision is split out into the companion article introduced at the start.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (39 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. The Lineage on a Single Page

This section works through who supplies what, and which generation it is, in that order. OpenHarmony is a project; HarmonyOS is a commercial product. NEXT is not a separate project standing alongside OpenHarmony — it is a name that distinguishes one generation of HarmonyOS from another.

First, Separate the Project from the Commercial Product

Do not let a discussion run on the name “Hongmeng (HarmonyOS)” alone; check which row of the following table is meant.

Next, Separate the HarmonyOS Generations

Re-arrange the rows of the table along a time axis and you can see at a glance where the insides of an OS with the same name were swapped out.

timeline
    title HarmonyOS generations and the presence of AOSP
    2019 : HarmonyOS 1.0 : For smart screens
    2021-2024 : HarmonyOS 2 to 4.x : A hybrid of AOSP and OpenHarmony : Android apps run
    2024 : HarmonyOS NEXT = 5 : AOSP-derived code removed : Android apps do not run
    2025 : HarmonyOS 6 : The NEXT name is dropped
    2026 : HarmonyOS 7 : Developer beta announced at HDC 2026

Figure 1: The HarmonyOS generations and the line at which Android apps stop running⁴³⁶

The line is NEXT (= 5) in 2024. Check first that experience with the generations before that line is not being mixed up with discussion of the generations after it inside your organization.

Also Distinguish Oniro, Which Branched from the Same Foundation

There is another lineage built on OpenHarmony: Eclipse Oniro. Its position is explained in detail in Section 9.

Put another way, OpenHarmony is the raw material, and HarmonyOS and Oniro are separate products made from that material. Picturing the relationship that Red Hat Enterprise Linux and Debian have to the Linux kernel gets you close to the right granularity. Unlike Linux, though, OpenHarmony covers not only the kernel but the UI framework and the app model as well, which makes it a fairly vertically stacked package.

3. What OpenHarmony Actually Is — What Is Inside It

The official OpenHarmony documentation describes the project as an open source project incubated and operated by the OpenAtom Foundation, whose purpose is to build an open source distributed OS framework for smart devices across all scenarios.¹

This section works in the order names of the parts, the layer structure of the OS, the configuration per device, collaboration between devices, and development boards. “Using OpenHarmony” means different configurations depending on the device you put it on.

Check the Terminology First

Proper nouns come thick and fast here, so here is a minimal glossary.

The Four-Layer Architecture

The architecture has four layers, from the bottom up: the kernel layer, the system service layer, the framework layer and the application layer.¹

• Kernel layer: a multi-kernel design in which you choose Linux or LiteOS according to the resource constraints of the device. The kernel abstraction layer (KAL) hides the implementation differences and gives the layers above a common view of process, memory, file system, network and peripheral management. Drivers are written against HDF (Hardware Driver Foundation), OpenHarmony’s own unified driver foundation.
• System service layer: the distributed soft bus (DSoftBus), distributed data management, the distributed scheduler, multimodal input, graphics, security, AI and so on.
• Framework layer: the application framework and the Ability framework for C/C++/JS, and the ArkUI framework for JS.
• Application layer: system apps and third-party apps.

The Kernel Is Not Fixed to One Choice

What matters here is that the multi-kernel design is what gives OpenHarmony its character. Under one OS name, LiteOS-M runs on an MCU while the Linux kernel runs on a richer device. The question “what is OpenHarmony’s kernel?” has to be met with the counter-question “which system type are we talking about?”.

The Three System Types

The four layers divide responsibilities inside the OS; the three system types divide configurations to match the device. They are two different axes. The official documentation defines three basic system types.⁸

Starting at 128 KiB is what makes this OS unusual. The official documentation puts it as supporting RAM from a few hundred KiB up to the GiB class.¹ The design is componentized: you build up a configuration and leave out the components you do not need.

Distributed Capabilities as the Core Concept

The first characteristic the official documentation puts forward is collaboration between devices centered on DSoftBus (the distributed soft bus).¹ It is a common foundation that discovers, connects and networks nearby devices and transfers data regardless of the transport, with distributed data management (synchronizing data across devices) and the distributed scheduler (starting and migrating apps across devices) layered on top of it.

For a Standalone Device, Work Out Which Features You Actually Need

This idea of treating several devices as one super device is also the basis of the HarmonyOS experience that links smartphones, tablets and in-car systems. Put the other way round, if you only embed it in a single standalone device, you will not use half of OpenHarmony’s headline features. That point bites in an adoption decision.

Development Boards and Hardware

In the official list this article consulted, as of July 2026, there are 22 development boards supported by the community.⁹ Broken down by system type, the examples look like this.

• For the standard system: the HiHope HH-SCDAYU200 with a Rockchip RK3568, and the MILOS_Standard0 with an NXP i.MX8M Mini.
• For the small system: the BearPi-HM Micro with an STM32MP157A.
• For the mini system: the Hi3861, STM32F407, ESP32, and the RISC-V HPM6750, among others.

The list is not limited to Chinese SoCs; chips from ST and NXP are included as well. Some products carry descriptions that assume industrial use: the MILOS_Standard0, for example, lists high-performance measuring instruments for industry and medicine, industrial control and HMI, transportation, disaster prevention and buildings among its applications.⁹

4. What HarmonyOS Actually Is — The AOSP Hybrid Era and NEXT Onward

HarmonyOS is Huawei’s commercial OS product. The thing to hold on to here is that the insides differ from generation to generation under the same name, HarmonyOS.

HarmonyOS 1.0 (2019)

The first device it shipped on was not a smartphone but a smart screen (Honor Vision). This was the generation before OpenHarmony was donated to the OpenAtom Foundation, and it was not in circulation as a smartphone OS.⁴

HarmonyOS 2 to 4.x (2021 to 2024)

This is the generation that rolled out on smartphones. It combined AOSP with OpenHarmony, and devices of this generation could run both Android apps (APKs) and HarmonyOS apps. The understanding that spread in Japan, that HarmonyOS must be the Chinese version of Android, took hold because that is what this generation looked like in practice.³

HarmonyOS NEXT (= HarmonyOS 5, 2024)

The AOSP compatibility layer and the Android libraries were removed, and Android apps stopped running. Only HarmonyOS native apps run.³

“HarmonyOS native app” does not mean written in ArkTS alone. You can combine modules written in C/C++ against the Native API (NDK), and Cangjie, a language Huawei developed in-house, is also offered as an option for HarmonyOS app development.¹⁰¹¹

HarmonyOS 6 Onward (2025 Onward)

The “NEXT” name was dropped, and it became simply HarmonyOS 6. At HDC 2026 in Dongguan on June 12, 2026, the start of the HarmonyOS 7 developer beta was announced, together with the statements that HarmonyOS 6 had passed 66 million devices, that registered developers had passed 11 million, that more than 400,000 apps and services were available in the app store, and that HarmonyOS had become the second largest smartphone OS in China.⁶

Do Not Confuse HarmonyOS Adoption Numbers with the Number of Commercial OpenHarmony Versions

In the same announcement, Huawei also said of the OpenHarmony side that “more than 100 commercial versions have been released”.⁶ In other words, for Huawei OpenHarmony is at once the foundation of its own smartphones and the supply source from which other companies build industrial products.

Treat the Regional Picture Separately by Device Category

The regional picture is what matters most in practice when seen from Japan, and lumping all devices together here leads to the wrong decision. What has to be separated is smartphones and the app distribution ecosystem on one side and the firmware of peripheral devices such as wearables on the other.

• Smartphones and the app market are China-centric. The HarmonyOS 6 product page is provided on the Chinese site,¹² while Huawei’s global consumer site (consumer.huawei.com/en/harmonyos/) is still the HarmonyOS 2 landing page as of July 2026.¹³ It is reasonable to treat HarmonyOS native apps for NEXT-series smartphones, and the market that distributes them, as effectively a China-domestic matter.
• The HarmonyOS brand, on the other hand, also ships on devices outside China. Huawei distributes HarmonyOS 5 and 6 firmware updates to smartwatches in global markets as well, so it cannot be said that “HarmonyOS 5 and later = China only”.¹⁴

So if a Japanese company talks about building and distributing a HarmonyOS app, that comes as a package with a business decision about the Chinese market. OpenHarmony, on the other hand, can be obtained and used by anyone in any region, so the two should be treated as completely separate decisions.

5. Are an “OpenHarmony App” and a “HarmonyOS App” the Same Thing?

Having a common language and app model is one thing; being able to move an app across unchanged is another. This section separates what is shared from what is Huawei’s own.

What Is Shared Is the Skeleton of the App Model

What they share is the skeleton of the app model: ArkTS (a declarative-UI language that extends TypeScript), ArkUI (the declarative UI framework) and Ability (the unit of execution of an app). Look at the release notes for OpenHarmony 6.0 Release and you find items that closely resemble the HarmonyOS feature additions: extended layout capabilities in ArkUI, ArkWeb’s Chromium kernel updated from 114 to 132, the addition of AppServiceExtensionAbility, kiosk mode support and so on.¹⁵

What Differs Is the SDK, the Distribution Platform and the Cloud APIs

The differences are in what surrounds them. HarmonyOS apps are built on the assumption of Huawei’s HarmonyOS SDK and DevEco Studio, the AppGallery distribution platform, and the cloud APIs of HMS (Huawei Mobile Services). A plain OpenHarmony system does not come with Huawei’s commercial environment as a set. So:

• You cannot install apps from AppGallery on your own device running OpenHarmony.
• Nor is there any guarantee that an app built for HarmonyOS will run as-is on real OpenHarmony hardware. You have to check, one by one, whether each API it depends on is a Huawei extension or OpenHarmony standard.

For a Device, Check Who Develops the Apps and Which APIs They Depend On

If you adopt OpenHarmony for a device, the right plan is to assume that the apps running on it will be written by you (or by the vendor of the distribution you adopt). Deciding to adopt it in the expectation that a body of Chinese apps comes with it will miss.

6. How to Read Versions and API Levels

This section separates checking the version number and the API level from checking compatibility between OpenHarmony and HarmonyOS. Similar numbers do not mean the same environment.

Map OpenHarmony Versions to API Levels

OpenHarmony versions have API levels associated with them, and the README of the official documentation repository carries the list.¹⁶

The table below is the list in that README as consulted in July 2026. “Latest” is the classification used in the README itself; this table alone does not establish the current latest release or its maintenance status.

Cross-Check the README Against the Release Notes Index

This list is the one carried in the documentation repository’s README, but the release notes index in the same repository lines up newer entries still: 6.1 Release (March 8, 2026) and 6.0.0.1 / 6.0.0.2.¹⁷ Even inside the official documentation the “latest version” wording can fail to keep up, so when you pin a version down, look at the release notes index as well as the README.

The Same API Level Does Not Necessarily Mean the Same Set of APIs

HarmonyOS has API levels assigned in the same way, and Huawei’s developer documentation publishes release notes per version.¹⁸ The numbering schemes are close enough to be confused, but OpenHarmony API Level 20 and HarmonyOS API Level 20 do not necessarily denote the same set of APIs. When you check a specification, always stay aware of which documentation you are reading.

7. Maintenance Windows — The First Number an Equipment Maker Should Check

Being able to obtain the source and being able to receive fixes for as many years as you need are different things. This section goes through the community’s maintenance policy, the dates for individual branches, and the operating life of the device, in that order.

First, Check the Maintenance Policy for Release and LTS

The OpenHarmony community defines the lifecycle of a branch, the period from release to end of maintenance, as follows.¹⁹

• The lifecycle of a Release branch is two years (one year of proactive maintenance plus one year of passive maintenance)
• The lifecycle of an LTS branch is 3.5 years (two years of proactive maintenance plus 1.5 years of passive maintenance)
• The proactive maintenance period is the period in which the community issues tagged versions to a plan and fixes defects and security vulnerabilities
• The passive maintenance period is the period in which no tagged versions are planned or released and only security vulnerabilities and defects rated critical or above are fixed

Next, Check the Maintenance Deadline for the Branch You Adopt

The maintenance schedule table this article consulted, as of July 2026, is as follows.²⁰ It is a list of the branches published there, not a statement that OpenHarmony as a whole has reached end of maintenance.

Put this table together with the release notes index and there are three points to check.

1. The last LTS branch is 3.0-LTS (September 2021). There were LTS branches before it as well: 1.1.0 LTS (April 2021) and its series (1.1.x LTS) remain in the release notes.¹⁷ But every branch published from 3.1 onward is a Release, which means two years of maintenance.
2. Every branch listed in the table had reached end of maintenance as of July 2026. The 5.x series and 6.0 Release are not in this table yet.
3. This is an order of magnitude away from the premises of a device that runs for ten years. Set against Windows 11 IoT Enterprise LTSC 2024, which is supported for ten years until October 2034, the difference in design philosophy is plain.

Finally, Decide Who Supports the Device’s Operating Life

This is not to say that OpenHarmony is inferior; it is that the usage pattern of putting a community build into a product and leaving it there is not what the project is designed for. In real industrial adoption, the vendor of a commercial distribution maintains its own branch and sells that maintenance. When Huawei says that OpenHarmony has released more than 100 commercial versions, it is pointing at the depth of that layer.⁶

8. Licensing and How to Get the Source

Licensing

OpenHarmony is not a single-license project. The license differs per repository.

When you embed it in a product, the rule is to check the LICENSE of each repository you actually link against, one at a time. Summarizing it as “OpenHarmony is Apache 2.0, so we are fine” makes you miss the GPL obligations in the kernel part.

Check the Conditions for Modification and Redistribution Separately from the Notices You Ship

Modification and redistribution themselves are not prohibited by any of these licenses. But you have to satisfy the conditions attached to each part you use.

Apache 2.0 permits modification and redistribution while requiring that the full license text be included, that copyright and other attribution notices be retained, that changes to modified files be stated, and that any NOTICE file be carried forward.⁵

BSD 3-Clause requires that the copyright notice, the list of conditions and the disclaimer be reproduced (if you ship binaries only, that means putting them in the manual or other accompanying materials) and prohibits using the rights holder’s name in endorsements.²¹

In other words, if you embed it in a device and ship it, work to prepare license notices on the product side is unavoidable. Decide at design time how you will satisfy that: the back matter of the manual, a “License information” screen in the device’s settings, an accompanying text file, or something else.

Also Check Source Provision for the Kernel and Credit for the Documentation

If you modify and distribute the Linux kernel of the standard system, a separate obligation arises under GPLv2 to provide the corresponding source code. If you reproduce the documentation in internal material, CC BY 4.0 credit is required.²²

Getting the Source

Distinguish the Development-Branch Example from Pinning a Release Version

The source is fetched with the same repo tool used for Android. The procedure given in the official documentation is as follows.² This example fetches the development branch with -b master. To pin a release version, switch to the branch name or tag described below.

repo init -u https://gitcode.com/openharmony/manifest.git -b master --no-repo-verify
repo sync -c
repo forall -c 'git lfs pull'

Hosting is offered on gitcode.com, gitee.com and a GitHub mirror, with both SSH and HTTPS available.² If you want to fetch a pinned release version, switch the branch name to a version name such as OpenHarmony-6.0-Release, or to a tag (refs/tags/OpenHarmony-v6.0-Release). There is no special registration or authorization procedure.

Check the Structure Under QEMU Before Buying a Board

If you want to examine the structure before buying a real board, there is also a route that runs it under QEMU. The device_qemu repository carries emulation procedures for Arm Virt (LiteOS-A / Linux), Cortex-M4 (mps2-an386), Cortex-M55 (mps3-an547), RISC-V (riscv32_virt), Xtensa (esp32) and C-SKY (SmartL_E802).²³

9. The European Branch — Eclipse Oniro

A Project That Builds Different Extensions on the OpenHarmony Foundation

Something Japanese engineers easily overlook is the Oniro project run by the Eclipse Foundation. The project page states explicitly that “Eclipse Oniro for OpenHarmony is built on top of the base layer of OpenHarmony, an open source project incubated and operated by the OpenAtom Foundation”, and sets out a direction of adding React Native support, an Eclipse Theia-based IDE, the Servo web engine and so on for European and global markets. The licenses are Apache 2.0 and MIT, and the project state as of July 2026 is Incubating.⁷

Evaluate the Difference in Governance Separately from the Adoption Risk

For an organization constrained by a procurement policy under which an OS originating in China is difficult, it is worth knowing that an option in the same lineage exists under a European foundation’s governance, if only to widen the scope of the assessment. That said, its Incubating status, and the fact that its community is nowhere near the scale of OpenHarmony proper, are adoption risks in their own right.

10. Summary — Talk About the Three Separately

• OpenHarmony is the OpenAtom Foundation’s open source OS project. It covers everything from a 128 KiB MCU to rich devices with 128 MiB and up as one OS family, and anyone can obtain the source. This is the thing you assess for adoption in a device.
• HarmonyOS is Huawei’s commercial OS product. The 2 to 4.x generations rolled out on smartphones were a hybrid with AOSP and ran Android apps, but from NEXT (= 5) onward AOSP is gone and it is a world of HarmonyOS native apps. The development language is not limited to ArkTS. Smartphones and the app market are China-centric, but keep that separate from the rollout of wearables and the like outside China (Section 4).
• Eclipse Oniro is a European lineage built on top of OpenHarmony. As of July 2026 it is at the Incubating stage, but from the point of view of where governance sits it is a distinct option.

Once you have separated the product names, check the configuration, what the apps depend on, who maintains it and the licensing, in that order. That is how to read this article across into an adoption study.

Once you can talk about these three without mixing them up, internal discussion gets a great deal more concrete — because instead of “shall we adopt HarmonyOS?”, you can translate the question into “which SoC do we put the OpenHarmony standard system on, with maintenance from which commercial distribution?”. The practical decisions beyond that — maintenance windows, hardware options, development environment and procurement, compared side by side with Windows IoT and embedded Linux — are split out into the companion article.

Related Articles

• Is OpenHarmony a Viable OS for Industrial Equipment? — Compared with Windows IoT and Embedded Linux
• Which Windows Should You Put on an Industrial PC? — A Practical Guide to Windows IoT Enterprise / LTSC
• Practical Options After Windows 10 End of Support

Related Consulting Areas

At KomuraSoft LLC we handle the selection of the OS and runtime platform for equipment and business systems, the triage of whether existing Windows applications can be migrated, and reviews of configurations intended for long-term operation. You are welcome to come to us at the stage of “a new OS has come up as a candidate, but we don’t have enough to base a decision on”.

• Technical Consulting and Design Review
• Windows Application Development
• Contact

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Frequently Asked Questions

Common questions about the topic of this article.

Are OpenHarmony and HarmonyOS the same thing?

No, they are not. OpenHarmony is an open source OS project incubated and operated by the OpenAtom Foundation; anyone can obtain the source code, and it is distributed under open source licenses such as Apache License 2.0. HarmonyOS, by contrast, is Huawei's commercial OS product, which builds on OpenHarmony as its foundation and adds Huawei's own frameworks, app distribution platform (AppGallery) and cloud services (HMS) on top. It is not the case that "because OpenHarmony is public you can read all of the HarmonyOS source", nor that "a device running OpenHarmony can install apps from AppGallery". The relationship between the Linux kernel and a commercial Linux distribution is a useful mental model.

What is HarmonyOS NEXT, and how does it relate to HarmonyOS 5 and 6?

HarmonyOS NEXT is the name given to the generation of HarmonyOS from which the Android (AOSP) derived code was removed; as a product version it corresponds to HarmonyOS 5. The HarmonyOS 2 to 4.x generations rolled out on smartphones combined AOSP with OpenHarmony, and Android apps (APKs) ran on them (the earlier HarmonyOS 1.0 was the generation that appeared in 2019 for smart screens). From NEXT onward the AOSP compatibility layer is gone, and only HarmonyOS native apps run. "Native app" here is not limited to ArkTS: the C/C++ Native API (NDK) and Cangjie, Huawei's own language, are also among the options. In the following HarmonyOS 6 the NEXT name was dropped entirely, and it is simply called HarmonyOS 6. At HDC 2026 in June 2026, the developer beta of HarmonyOS 7 was announced.

Can I install HarmonyOS apps on a device I built with OpenHarmony?

Do not assume you can. OpenHarmony and HarmonyOS share a common lineage in ArkTS and ArkUI, and their API level numbers are assigned similar values, but HarmonyOS apps are built on the assumption of Huawei's HarmonyOS SDK and AppGallery, and a plain OpenHarmony environment has neither. Conversely, there is no guarantee that an app built for OpenHarmony will run as-is on real HarmonyOS hardware. If you adopt OpenHarmony for a device, plan on the basis that the apps will be written by you (or by the vendor of the distribution you adopt) against OpenHarmony's APIs.

How long is OpenHarmony supported for?

The community lifecycle policy defines a Release branch as two years (one year of proactive maintenance plus one year of passive maintenance) and an LTS branch as 3.5 years (2 years plus 1.5 years). However, the last LTS branch was 3.0-LTS in September 2021 (there was a 1.1.0 LTS before that), and every branch published from 3.1 onward has been a Release. If you use this OS in a product that is expected to run for ten years, as industrial equipment is, the community maintenance window is not enough on its own: you either buy vendor maintenance from a commercial distribution or you need an in-house capability to maintain your own branch.

How can a developer in Japan get started with OpenHarmony?

The source code can be obtained with the repo tool from mirrors on gitcode.com, gitee.com or GitHub, and there are no special procedures such as account registration or export permits. Official documentation is available in two languages, Chinese and English; there is no Japanese version. You can also run it under QEMU to examine the structure before buying a real board. The realistic starting point is the "Device Development" entry in the English documentation, beginning with deciding which system type (mini / small / standard) you are targeting.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.