epic: Chatwoot community edition(CE/FOSS) and enterprise edition(EE)

[vishnu-narayanan]

Is your feature request related to a problem? Please describe.

We introduced the enterprise folder and dual licensing with #3209. The enterprise folder can be removed to have a fully MIT compliant version. Make it easy to run fully open-source software.

Describe the solution you'd like
Start publishing both CE and EE editions when cutting a release with the CE version stripped of all proprietary code.

• Chatwoot FOSS repo
• Chatwoot EE and CE release artifacts
• Chatwoot EE and CE docker images

Todo

• Run ci tests against foss codebase for every PR #4341
• Run gh action to generate a docker image for CE edition #4388
• Modify Linux installation script to support CE installation

Describe alternatives you've considered
Use the existing repo to create both CE and EE releases. No separate FOSS repo.

Additional context
Similar to Gitlab and PostHog release model.

[vishnu-narayanan]

Single Repo approach

The current repo chatwoot/chatwoot serves as the canonical source of truth. All development and discussions happen over this repo. There will not be a separate chatwoot-foss repo.

Creating release artifacts

When cutting a release, we could have an automated GitHub action that could strip the /enterprise folder and create a ce artifact along with ee. This can be accomplished by creating a separate ce tag.

For example,
https://github.com/chatwoot/chatwoot/archive/refs/tags/v2.3.2.tar.gz
https://github.com/chatwoot/chatwoot/archive/refs/tags/v2.3.2-ce.tar.gz

Creating docker images

This can be accomplished via an additional docker file for CE edition which we can use to build the CE docker images at dockerhub.

The tags can be v2.3.2-ce, latest-ce etc.

The docker pull would look like docker pull chatwoot/chatwoot:latest-ce.

Advantages

• No two separate repos to maintain and keep in sync.
• Forks/stars/downloads and all other metrics at one location.
• Docker metrics also across one repository

Disadvanatages

• There won't be a fully MIT repo to clone easily.
• Release process with two repos would provide a clear separation between the releases. Tags can remain same across both versions.
  https://github.com/chatwoot/chatwoot-foss/archive/refs/tags/v2.3.2.tar.gz
  docker pull chatwoot/chatwoot-foss:latest

[vishnu-narayanan]

Multi Repo Approach

The current repo chatwoot/chatwoot serves as the canonical source of truth. All development and discussions happen over this repo. There will be a separate chatwoot-foss repo which will be stripped of all proprietary code and fully MIT.

How?

master, develop and other release branches would be kept in sync with chatwoot-foss repo. Feature branches can be skipped. Also, the tags should be kept in sync.

This would be tedious and error-prone to do manually. Probably an automated way via a GitHub action.

Advantages

• Fully MIT licensed repo of Chatwoot will be available for everyone.
• Existing release process would be sufficient to generate both versions.
• Tags can be the same across both releases. Users should be able to just change the repo name to get the EE or CE version.

Disadvantages

• Need to have an automated way to keep both repos in sync.
• Forks/stars/downloads and all other metrics will be distributed.
• Docker metrics will also be spread across two repositories.

[vishnu-narayanan]

To start off,

• Run ci tests against foss codebase for every PR (strip enterprise folder and spec)
• Run gh action to generate a docker image for CE edition
• Modify Linux installation script to support CE installation

[pranavrajs]

@vishnu-narayanan Sounds good

[pranavrajs]

Closing this as the docker builds are complete and omnibus installation would be tracked over https://github.com/chatwoot/product/issues/204

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.