RFC-46: App Editions for Marketplace

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 -

  1. App editions will be only for cloud apps, available for both Connect and Forge, and will be for Paid via Atlassian(PvA) apps only.
  2. 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.
  3. Generally, the delivery iterations for App Editions will follow the below milestones:

  1. 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.
  2. 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.
  3. 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.

21 Likes

Hi @SarahAllen,

Thank you so much for this RFC. Not only for the fact that Atlassian is reviving the App Editions but also for providing such a detailed RFC. It is very visible that a lot of thought has been put into App editions and this RFC, and that is much appreciated.

It is late at night now so I will start looking into the Asks first thing tomorrow, but I just wanted to express my gratitude for the meticulous RFC :pray:

28 Likes

@SarahAllen thanks for sharing this. Very good to know that this important initiative is being revived/unpaused.

Also agree with Remie that this is a comprehensive and helpful RFC. At first glance, I can’t find any major concerns for us.

One thing we had already noted in the first incarnation of this is that we’d need to have the option for our existing customers to be mapped onto the Advanced edition by default, as opposed to the Standard edition. Is that something you plan to accommodate?

8 Likes

Thanks for the RFC, glad to hear that App Editions are being revived :slight_smile:

This is, I believe, different from when App Editions were announced last time, and a welcome change! I just wanted to highlight that we’d expect customers to only be able to trial our app for free once. In the previous App Editions it sounded like there would be 2 free trials for both editions (see my comment here), and I hope this change will persist for Milestone 3.

4 Likes

Ok, here is my feedback!

Definitely a +1 for App Editions. We have multiple new features on our roadmap for which we are contemplating creating new apps just to ensure that we can differentiate in pricing between regular users and power users. However, from a marketing perspective, having the ability to keep a single Marketplace listing and provide that distinction in our offering is a huge win for us.

Now to answer the Asks:

Does the developer experience sufficiently meet your needs required to extend your app with editions?

I’m really happy to see that the customer edition is part of the lifecycle event, license API, conditions and query string. There are however two places missing from a Connect app perspective that will help cover all use cases:

  1. Can it be included in the AP.context.getContext() or any of the other Javascript APIs?
  2. Can it be added to context parameters?

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.

We will mostly be using the Lifecycle event and the QSP, although when available in the Connect Javascript API we would also use this.

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?

Yes

Feedback and reactions on the overall publishing, reporting, and customer experience.

I agree with @danielfranz that there currently doesn’t seem to be a migration path for existing customers. How are we expected to transition existing customers into App Editions once we decided to mark certain features as “Advanced”?

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.

It would be great if we can define our own plans, which I think is currently not part of any of the milestones. App Editions are also a great way to introduce pay-per-use modals in which you can grant a customer X resources based on their plan. Having the ability to introduce more than just the Standard and Advanced plans would help navigate the gap between a <100 user and >10K customer needs.

7 Likes

We also would like to map to the Advanced edition by default.

As with others just wanted to say thanks for the comprehensive RFC @SarahAllen - no major risks or concerns from our side and excited to see this progressing to an RFC stage now with an EAP incoming.

Would be good to get clarity on how customers might be impacted if some things they are used to are then locked in an advanced plan if the default is to map them to standard plan - is there some kind of grandfathering period for them to upgrade or learn to work around new limitations?

1 Like

A question about milestone 4: Is there a reason to get rid of the free starter tier (FST)? Personally, I like that apps automatically become paid when the user threshold is crossed. (Sorry if I misunderstood the original comment.)

Everything else sounds great!

1 Like

Will there be a configurable or constant maximum user tier for Free edition?

3 Likes

Thank you, everyone, for the amazing feedback and reception. I’m glad that our proposal broadly aligns with you and is comprehensive. We would like to encourage more feedback from other partners as well, as that will help us further.

Answering Qs from the comments so far -

@danielfranz , @remie , @raimonds.simanovskis -
#1 - Regarding mapping an app directly to an advanced edition, we do not plan to accommodate this in M2. However, we are discussing the use case, which will most likely land after Milestone 2. We still need to determine when this will happen.

#2

This is, I believe, different from when App Editions were announced last time, and a welcome change! I just wanted to highlight that we’d expect customers to only be able to trial our app for free once. In the previous App Editions it sounded like there would be 2 free trials for both editions (see my comment here ), and I hope this change will persist for Milestone 3.

@BenRomberg - Ben, currently during the advanced trial period, customers will pay for the subscription they are on, mostly standard. We would like to carry this forward to Milestone 3 as well. This is good feedback and noted.

#3 - @remie , for your question regarding the developer experience, someone in the team will follow up and share a reply. Regarding usage-based/metered billing models and the ability to offer customized editions beyond Standard and Advanced, these are not part of any of the milestones yet and will be considered and evaluated once we deliver the above releases. These are things that we have discussed but don’t have a definitive plan yet.

#4

Would be good to get clarity on how customers might be impacted if some things they are used to are then locked in an advanced plan if the default is to map them to standard plan - is there some kind of grandfathering period for them to upgrade or learn to work around new limitations?

@awignall - For M2, the idea and guidance are that your current app and pricing will map to a standard plan, and customers will not lose any feature or pricing difference because an advanced app has been introduced. In the future, we will offer the ability to map the existing app to an advanced app directly with a smaller feature set app being called standard. When we start offering that, your existing customers should automatically move to the advanced plan as well so as not to lose the capabilities they have been used to. They will continue to be on an advanced plan until they choose to downgrade. But in that case the idea would be that the pricing of an advanced app is not increased just because we now have a standard app with a subset of the advanced app features. Please let me know if you have a differing point of view.

#5

A question about milestone 4: Is there a reason to get rid of the free starter tier (FST)? Personally, I like that apps automatically become paid when the user threshold is crossed. (Sorry if I misunderstood the original comment.)

@AaronMorris1 - Thank you for your feedback. Something that we can consider as we get closer to the release. Our rationale was that with a free-for-all version of an app, a free starter tier may no longer make sense, but I do see your point. As we get closer to the milestone, we will keep this feedback in mind and discuss.

#6 -

Will there be a configurable or constant maximum user tier for Free edition?

@lexek-92 - Our current thinking is no. But I would like to hear more thoughts and opinions on how you would want the user tier to be. If you have different options in mind and pros/cons, please feel free to share, as that helps shape our thinking about the free edition.

Thank you!

P.S. if you’re attending Team '24, some of us will be around and would love to engage with you and gather your feedback/discuss further.

2 Likes

Hi @PremankuChakraborty – Thank you for the follow-up! As you continue to think about and design the Free App tier, my primary request would be to maintain consistency with Atlassian’s own pricing strategies as much as possible.

Atlassian doesn’t provide free-for-all versions of their apps (AFAIK). Instead, they provide user-capped free versions that automatically upgrade to Standard versions when the user cap is exceeded.

I believe this is intended to support philosophies such as “low barrier to entry” and “land-and-expand”:

So, perhaps introducing the capabilities for Advance editions (which is great!), while user-capping and automatically upgrading the Free editions would move the Marketplace more in alignment with Jira’s and Confluence’s pricing structure?

2 Likes

Hello @PremankuChakraborty - thank you for your answers!

So far, my understanding with the original announcement of App Editions a while ago was that the “free” tier was limited and not suitable for current free-for-all tier editions of the same app.

So can you confirm that once the M4 is reached, we can de-list a currently free-for-all marketplace app and integrate it in the main paid marketplace app?

Thanks!

1 Like

Essentially, it would work like the current FST, but within app editions framework.

1 Like

App editions would be completely useless to us if existing customers could not be migrated into the Advanced edition.

I think this is the case for most Marketplace partners because the majority of apps in the Marketplace are already ‘feature complete.’ This means that it is unlikely that vendors will come up with additional BIG and valuable features to justify an advanced version (and higher price) for the existing apps. We (like many others) have an understanding of the ‘standard’ and ‘advanced’ features of our existing apps, and we would love to slice them accordingly. However, without being able to convert existing customers into ‘Advanced,’ this is unfortunately useless.

It is a totally different story for new apps or apps with a roadmap full of ‘premium’ features to come, and here, app editions are great. However, this is likely to be the minority of apps.

4 Likes

I strongly urge you to consider keeping both the free starter tier with a 10 user cap and introduce a free tier for App Editions, allowing Marketplace Partners to opt-in for either one.

If you do not you will force all marketplace partners to implement usage restrictions for a free edition. This will mostly result in many apps no longer supporting FST / Free Edition because this is not a priority on their roadmap.

It is also a completely unnecessary additional workload for partners because the necessary restriction already exists with the FST. Why remove it?

8 Likes

I agree with the sentiment that has been voiced here: a lot of apps will want to downgrade “Standard” users compared to the current feature set which they will consider “Advanced”.

We need a comprehensive way to migrate existing customers and correctly manage expectations.

3 Likes

Thanks @AaronMorris1, @ernst.stefan, @lexek-92, @remie for the discussion on Free and FST and for sharing your different perspectives. While we have some time before making a decision, it seems from the discussion that partners desire both options - a free for all and an FST. My initial thought is that offering both choices for partners to select from might be a good starting point like Remie recommended. We will keep this in mind when we get closer to this.

Thanks @AdrianHuelsmann - We will certainly be focusing on enabling the migration of existing apps, pricing, and customers to the advanced edition while providing partners with the ability to create a standard version with limited features and lower pricing. However, it may not be available for Milestone 2. But it is definitely on our roadmap.

4 Likes

Thanks for the feedback. We had originally considered AP.context.getContext(), however had not included this due to its available also in the QSP. This is definitely something we will consider - it would be great to hear from other partners who consume either the QSPs or getContext method to support this.

Regarding context parameters - similar to lic, this would be come a standard parameter returned across all requests.

1 Like

The reason I asked for it to be included in the Javascript API is because we already have plenty of code that depends on AP.context.getContext(). It would remove the requirement to add QSP parsing, albeit I agree that this is relatively simple. I guess I mostly like having it because of completeness

Also, if I recall correctly, Connect apps using the cacheable app iframes pattern don’t have access to QSP; they only have AP.context.getContext() as a way to get license info.

4 Likes