How to manage code for a new OS platform (OpenHarmony Next)?

Feedback and Discussion Forum Adding Features
1

Hi, All

We want to bring Audacity project to a new platform called OpenHarmony Next. We think it would be very useful on this new system.

This is a big project, and we want to do it the right way. We need your advice on how to manage our source code.

What is the best way to set up our work so we can share it back with you later?

We have a few ideas:

- Work in a separate copy: We could keep our code separate from the main project. This might be easier for us at the start, but maybe harder to share back later.

- Work in a special branch: We can make a copy (a fork) of your project and create a new branch just for OpenHarmony Next.

Your suggestion: Is there another way you think is better? We are open to your ideas.

Our main goal is to add our work back to the official project project if you think it is a good fit.

Any help or advice you can give us would be great.

Best

2 Likes
2

The two methods you’re proposing are practically equivalent. The difference between a fork and a copy is whether or not you maintain the git history. Or do I misunderstand your question?

2 Likes
3

Hi,

This sounds like a strong and valuable initiative, and we appreciate your clear approach to planning it properly from the start.

From DigixValley’s perspective, the best option would usually be to work from a fork of the main Audacity repository and maintain a dedicated branch for OpenHarmony Next. This approach keeps your work close to the upstream project, makes syncing future changes easier, and gives you the best chance of contributing relevant improvements back later.

We would also suggest a few practical steps:

  • Keep platform-specific code as isolated as possible.

  • Submit reusable or platform-independent improvements upstream in smaller parts when possible.

  • Document build steps, dependencies, and architectural changes clearly.

  • Stay aligned with the project’s coding standards and contribution workflow.

  • Open an ongoing discussion or tracking issue so progress can stay visible to maintainers.

A fully separate codebase may feel simpler at first, but it can become much harder to merge back over time. A fork with a focused branch is usually the more sustainable path if upstream contribution is the goal.

Wishing you success with the OpenHarmony Next port.

Best regards,
Digixvalley

2 Likes