Disclaimer: This is a proposal and is subject to changes. Its purpose is to gather feedback. Kindly refrain from using this as a basis for building editions or making changes to your code.
RFCs are a way for Atlassian to share what we’re working on with our valued partner community.
It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.
Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!
- Publish: Apr 25, 2024
- Discuss: May 17, 2024
- Resolve: May 24, 2024
Dear partners,
We’re excited to announce app editions following a short break. We understand that this program has been eagerly anticipated, and we’re delighted to collaborate with you on this endeavor. At the moment, we are engaged in exploring the product, design, and engineering aspects while actively seeking input on the overall product and design experience.
App editions offer the chance to develop and monetize features customized for high-demand customers who are willing to pay more for added value. Simultaneously, it provides cost-effective options for price-sensitive customers, thereby maximizing the app’s addressable market. By incorporating app editions, you gain the ability to showcase various packaging options of a cloud app under one Marketplace listing. This pricing and packaging flexibility empowers you to customize pricing for your audience according to their willingness to pay. It allows you to capitalize on your cloud investments and gives you more control over your pricing and growth strategy.
A few things to begin with -
- App editions will be only for cloud apps, available for both Connect and Forge, and will be for Paid via Atlassian(PvA) apps only.
- Initially, we will have two editions - Standard and Advanced editions for apps. In the future, we will include Free apps as well. Once Free apps are integrated, the option for providing a free starter tier(FST) for Standard apps will be phased out. Customers on FST tier will need to transition to the Free edition of the app.
- Generally, the delivery iterations for App Editions will follow the below milestones:
- In Milestone 2, partners will have the ability to offer two editions for the app - Standard and Advanced. Having a Standard app is mandatory at a minimum; additionally, partners can choose to provide an Advanced app if they prefer. We cannot have only an Advanced app without having a Standard edition for an app.
- Note: During milestone 2, there will be no feature to archive an edition. This functionality will be developed in a future release. So once you have created an advanced edition of an app, it won’t be possible to remove the advanced version until we build the archival feature. You can always modify the advanced app though.
- During the EAP phase, there won’t be any change to the customer experience related to self-serve viewing or upgrading of editions. All customer requests during this phase will be facilitated by Atlassian advocates. Therefore, if a customer would like to upgrade from their existing standard app to the new Advanced edition, we’ll have a process in place for them or their Solution partner/Marketplace partner to reach out and submit an upgrade request. More details are provided below in the Customer Experience section.
Developer experience
We understand that there are multiple ways through which developers may request or utilise licensing information within their apps today. Some approaches are more generically utilised and available across more apps (such as the installation lifecycle event), whereas others may be available throughout later milestones. The developer experience details key touch-points for both integrating edition-level experiences into an app, as well as support for testing and evaluation. The additional information about editions(as an e.g. "capabilitySet": "capabilityAdvanced") will allow developers to write conditional logic against their code to differentiate the features for customers on particular editions depending on customer’s license state.
Please note that we are currently exploring this experience, so these ideas are subject to change. We value your feedback on which of the following approaches you find most important for evaluating an edition within your app, as it will guide us in prioritising them.
Connect Apps (and Connect modules on Forge)
Installation Lifecycle Event
The Connect installation lifecycle event currently provides key information associated with license state any time the app is installed or updated. The proposed change adds an additional property sharing the edition selected by the customer, as well as sending a new installation lifecycle event whenever the customer’s edition changes (similar to the behaviour today for domain or custom domain changes).
Connect License API
The Connect License API provides a license object which includes some base license information today. This capability proposes the extension of this with an additional capabilitySet property similar to the above installation event.
Connect Conditions
Conditions enable in-descriptor declaration of when a UI element of an app should be displayed to customers. Similar to the is_licensed condition, an evaluation of capability_set would provide an opportunity to show/hide modules depending upon the edition a customer has selected.
Inclusion in Connect iFrame QSPs
When loading a Connect iFrame, the license status is currently provided with a lic query string parameter. This capability proposes a further extension of this with a capabilitySet query string parameter which provides an app with the edition state at render time.
Forge Apps
Forge Custom UI / UI Kit
Forge’s Custom UI and UI Kit getContext() method currently returns an object which includes a LicenseDetails object which includes license information. We are proposing an extension to this to include the capabilitySet as an additional property or constant.
Forge Backend Functions
Forge’s new native node.js runtime provides an appContext similar to that getContext() method utilised by Forge Custom UI / UI Kit. This capability proposes an extension of this to support license within that context for backend function evaluation of license and capability set.
Publish experience
We will introduce a new section called ‘Editions’ in the menu options for each app for you to publish your edition details on Atlassian Marketplace.
Publishing edition details involves a three-step process. Below are the details of each process along with some key screens.
- Step 1 : Add and map features to edition type. This step allows you to provide the name of the feature, feature description and map it to the edition type. In addition to the features enabled in the code, you can also add service level differentiators to distinguish between editions. Aim to include at least one feature for both Standard and Advanced editions.
- Step 2: Price your editions. If your app doesn’t have a pricing plan, you can set pricing for both Standard and Advanced editions during this process. If your app already has a pricing plan, it will honor the existing plan as part of the Standard edition. You can modify the pricing plan of this edition if needed during this step. Note that the Advanced edition won’t offer a free starter tier, and its pricing for each tier must always be higher than the Standard pricing.
- Step 3: Review changes and submit for approval. Once the edition details are submitted, an approval flow with the Atlassian support team will be initiated. You can track the ticket and will receive updates once the team reviews it. Upon approval, your customers will be able to purchase the edition through a high-touch flow involving customer advocates in Milestone 2. If your app submission is rejected, you can make changes through the Manage editions action and resubmit for approval. Subsequent submissions of editions after approval will not initiate the approval process.
Reporting
During milestone 2, you will receive details about your customers using each edition of their paid apps. We aim to achieve this by incorporating a new field within each license featured in our license report. Using this field, you will easily identify the specific edition being utilized by each customer. As we progress through our milestones, we will unlock more reporting capabilities. During the initial release (milestone 2), the reporting features will be lightweight though, providing partners with essential information about the current state of a customer’s license.
Customer experience
During milestone 2, customers will not have the ability to view or self-serve an upgrade for editions of an app. This phase is a crucial part of our early access program, aimed at limiting access to only a specific group of customers identified by our partners until the official launch of the self-service experience in Milestone 3. More guidance about this will come in the future as we get closer.
- Throughout this early access phase, Atlassian/Marketplace partners/Solution partners will be empowered to engage with specific customers and communicate the availability of an Advanced edition of their app.
- If a customer opts to upgrade to the Advanced version, we will establish a streamlined process for initiating either an advanced trial or a direct upgrade (without going through a trial) by raising a ticket. Advocates will have the ability to either initiate a trial or directly move a customer to an advanced plan depending on what the customer’s request. If the customer opts to choose a trial, then during the trial period, they will be paying for the standard plan only. After the trial period ends or in between the trial period, customers can decide if they want to move to an upgraded subscription(again by raising another request) and at that point, the pricing will move to an advanced pricing plan.
- Upgrades are immediate. So, for example, if a customer is in the middle of their standard plan subscription period and decides to upgrade via an Advocate, Advocates can start the upgraded subscription plan immediately without having to wait for the billing period to end.
- In both scenarios, it is required that an Atlassian advocate facilitates the customer’s app upgrade.
- Upon upgrading to a paid subscription of an Advanced app, customers will receive an invoice for the price difference covering the remaining billing period for the Advanced app. This process closely resembles their current experience when upgrading to a higher version of the parent product.
Please be aware that we are currently working through the specifics regarding downgrades, and we will provide updates to this group later once available.
Asks
While we would appreciate any reactions you have to this RFC (even if it’s simply giving it a supportive “Agree, no serious flaws”), we’re especially interested in learning more about:
- Does the developer experience sufficiently meet your needs required to extend your app with editions?
- Which components of the developer experience are you most likely to utilise to extend your apps with editions? Your feedback helps us better prioritise and shape the ways in which apps can consume edition licensing information.
- Is awareness of a customer’s current edition type suitable for your app to determine what capabilities or features should be made available to customers?
- Feedback and reactions on the overall publishing, reporting, and customer experience.
- Anything else that we may be overlooking from a customer or partner experience perspective? While we may not be able to incorporate everything in Milestone 2, your feedback will assist us in prioritising features for future iterations, enhancing the capabilities of our editions.
More details about Milestone 2 timelines will be shared in Team '24.
