META: Reconsider "Apps" Naming

[julienrbrt]

WIP

Context:

The term "extensions" has been proposed to replace "apps", officially rebranding "Ignite Apps" to "Ignite Extensions" for several compelling reasons.

There has been some confusion among Ignite builders between "apps" and "app chains." The latter refers to application-specific chains scaffolded (or powered by) Ignite, leading to potential misunderstandings whenever "app" is mentioned. In addition, Ignite Apps are not truly "apps".

Historically, the Ignite Apps product was initially branded as Ignite Plugins. The rebranding aimed to better reflect the software's capabilities and complement the developer experience. In principle, the term "plugins" is most accurate as the current Ignite Apps product (now being proposed to be renamed Ignite Extensions), relies on a plugin system (Hashicorp plugin system, over gRPC).

Research into the terminology reveals subtle distinctions:

• Extension: Adds specific capabilities to an existing system without altering its core structure.
• Plugin: Adds particular features to an application, integrating deeply with its core functionality.
• Add-On: Enhances an existing application or software with additional features or services (that may include extensions and plugins).

From a marketing standpoint, "extensions" can suggest a broader scope of functionality and provide flexibility. They can imply integration with third-party services or applications, the ability to run background services such as indexers or database backends, and generally extend the core functionalities of Ignite. Also, "apps" may imply standalone capabilities, which does not accurately describe Ignite Apps.

The core maintainers and stewards of Ignite agree that:

Extensions are generally more lightweight, adding or modifying features without major changes to the core functionality. Plugins, on the other hand, integrate more deeply. While Ignite Apps are a form of "plugins", the term "extension" is more appropriate for Ignite's case and widely accepted in marketing contexts.

While adopting the term "Extensions" offers several benefits, it also presents challenges. The term "extensions" is often associated with browser add-ons, which are typically seen as lightweight and minor. This association might imply that these extensions cannot deeply integrate with an Ignite chain or be used to enhance the core functionality of an existing Ignite chain.

Acceptance Criteria:

Refactor:

• Update all Instances of "Apps" to "Extensions" in Core Directories
• Update all Docs to Refer to "Extensions"
• Update CLI Commands and Options to use "extensions"

Communication:

• Craft Blog Post Reflecting the Transformation of "Apps" into "Extensions"
• Produce Steps to Upgrade Existing Chain x App Configurations

  Available as a guide and referenced in release notes (breaking change)

Notes:

Previous Refactor:

• docs: change docs to use "apps" instead of "plugins" #3651
• refactor: rename CLI "plugin" command to "app" #3662
• refactor: rename plugins config file to igniteapps #3669

Existing plugin/app suggestions, proposals, to-dos, and needs triage issues:

• Ensure branches tracked by plugins are kept up to date #3367
• FIX: Prevent Overwriting ante_handler.go in App Folder #4011
• EPIC: Plugin Improvements #3927
• INIT: Support Plugins Written in Other Languages for Ignite Apps System #3935
• proposal: simplify the plugin system #3930
• Ignite Network commands documentation - Iteration 2 #2951

[wyhaines]

This came up in a call yesterday, and I had some thoughts that I wanted to get organized.

I spent some time, as a relative newcomer to the ecosystem, reading the documentation around the Ignite Apps, and I agree with the sentiments that the overloading of the term "app" makes this confusing, for all of the reasons listed in this discussion.

I did some brainstorming on this, and I landed on three suggestions for alternative names:

• Extensions -- my reasoning is similar to the reasoning above; it implies something that is added onto the core, to extend it's functionality, without changing the core.
• Components -- this is similar to extensions, and implies a modularity to the core, with the ability to add additional capabilities via the component architecture.
• Packs -- this one, I think, has less connotative baggage than the other two, allowing it's meaning to be more specifically defined for the context of the Ignite CLI. A pack is a package of functionality that is being added. It, I think, also implies the same sort of looser coupling with the core that extension does, but it doesn't have the same level of already-assumed meaning that extension does.

Were I the Ignite CLI emperor, I would lean toward pack, but I think that either it or extension would be similarly flexible as a replacement for app while being far less confusing.