docs/ECOSYSTEM.en.md

Rama main · réplica de lectura del repositorio original.

# Community Derivatives And Ecosystem Collaboration

BailingHub welcomes independent distributions, industry adaptations, executors, channel adapters, and other integrations built on the open-source core. We also welcome independent ACC implementations that do not use BailingHub code.

A community project does not need to become part of BailingHub, and it is not required to contribute every modification upstream. Independent names, product directions, maintainer teams, and governance models are respected. When an improvement is broadly useful, we welcome an Issue, Discussion, or Pull Request to improve the upstream project together.

## Ways To Participate

| Path | Suitable work |
|---|---|
| Upstream contribution | Bug fixes, contract improvements, documentation, tests, and reusable capabilities that benefit all users. |
| Community distribution | An independently maintained BailingHub derivative for a particular industry, deployment environment, or user experience. |
| Ecosystem component | Model, executor, channel, storage, business-system connector, SDK, or deployment-panel integration. |
| Independent ACC implementation | A runtime or tool that implements ACC without depending on BailingHub code. |

## Official Listing Principles

Once qualifying community projects exist, BailingHub will create a public ecosystem page that makes strong independent work easier to discover. A project requesting a listing should:

- provide a publicly accessible project, documentation, or product page;
- identify its maintainers, independent status, and relationship to BailingHub or ACC;
- comply with the licenses, NOTICE files, and attribution requirements of the code and dependencies it uses;
- state the compatible BailingHub or ACC versions, major differences, and intended use cases;
- contain meaningful maintained work rather than only replaced names, logos, or screenshots;
- avoid implying official BailingHub security certification, service warranty, or maintenance responsibility.

An official listing means that an independent project is useful for the community to discover. It is not certification, a quality warranty, official endorsement, or a security audit. Each maintainer remains responsible for their own distribution, service, and users.

## Names And Origin

Community distributions should use their own names and visual identities. Truthful statements such as "based on BailingHub", "compatible with BailingHub", or "implements ACC" are welcome, but a project must not imply that it is an official BailingHub distribution or that it has received certification or endorsement that was not explicitly granted.

The [LICENSE](../LICENSE) and [NOTICE](../NOTICE) files govern code use and redistribution. Apache License 2.0 does not automatically grant rights to project names or marks.

## The Relationship We Want

We do not treat community derivatives as competition that must be prevented. Independent projects can explore different industries, delivery models, and product directions. Reusable capabilities can flow upstream, while specialized capabilities can remain independently maintained. BailingHub is willing to list strong implementations, maintain compatibility discussions, and collaborate on documentation, adapters, and releases when both sides agree.

For now, introduce your project or collaboration proposal through a [Feature request](https://github.com/bailinghub/bailinghub/issues/new?template=feature_request.yml). A dedicated ecosystem listing and submission path will be established when the first qualifying community project appears.