RFC-60: Marketplace Monetization Strategies

[nick]

Thanks for publishing the RFC @SarahAllen, great to have a broader conversation around this before too many decisions are made (thinking about one-way vs two-way door decisions).

Before we get in to Easy Agile’s current thinking here are a few items I believe are worth clarifying for the Marketplace Partner audience just so we’re on the same page:

• Is ‘site based’ and ‘multi-instance’ used interchangeably? i.e. are sites = instances in this RFC?
• Shall we standardise on ‘subscriptions’ and drop ‘license’? License feels like a hangover from Server days.
• The USD1bn Marketplace GMV cited is total (i.e. Server, DC, Cloud). Are you able to share Cloud GMV for context?
• Is it possible to get a diagram showing what combinations of subscription and pricing are possible? As a few folks have noted it is complicated, and if we are struggling to understand how will Atlassian present this to customers?
• Should ‘multi-instance licensing’ be called ‘Organisation wide subscription’ to align with the language Atlassian Admin uses (i.e. Organisation/Site/Product)?

Here is Easy Agile’s current thinking on the RFC itself:

1. This is a massive change to the whole operating model of the Atlassian Marketplace.

• How do we model this?
• How is Atlassian modelling this?
• Essentially, how is this NOT revenue negative in the short term and how do Marketplace Partners bridge the gap?

2. Customers will not benefit from lower costs as:

• decoupling adds complexity to the sales cycle and ongoing application user and usage management,
• if customers want Marketplace Partners to meet the demands of ISO27k, SOC 2, custom legals, etc then they must pay an Enterprise price,
• Marketplace Partners can not sustain a decimation in their revenue, so will have to increase the per user pricing to make up the shortfall, or otherwise we’ll go out of business and that will leave the customer without any solution, and
• as a result this leads to more complexity for customers, and they will ultimately pay around the same as they do today.

3. This will add a significant administration burden for customers with multiple apps:

• Admins currently do not have to choose who has access to an app.
• Assuming they don’t set and forget this becomes an ongoing job increasing hours spent on non value add tasks for them.
• With every app having a different way of administering users this impact will be multiplied.
• In large complex organisations this could amount to a cost increase beyond anything they would potentially save. Not to mention the headache with the new complexity.

4. Solution Partners are currently trying to get up to speed on selling solutions, and this is just yet another distraction on the journey towards more solution selling in the Marketplace.

5. Putting in place mechanisms for these options in our own accounting and business management systems is non-trivial, all of our dashboards and historical business metrics would suddenly become harder to draw trends and insight from. That would leave many of us blind to what is occurring and slow decision making.

At Easy Agile we believe every member of a Product & Engineering group will get value from the Easy Agile product suite, and as an agile solution we believe visibility and transparency brings the best outcomes and leads to the most effective communication and alignment across a company. For this reason I believe we would continue to couple the Easy Agile user tier with the Jira user tier.

Easy Agile believes Atlassian needs to consider an option 4 - status quo - and focus energy on educating customers on the value prop that exists with Apps today, and avoiding adding a ton of complexity to sales during a difficult phase of the macroeconomic cycle.

Thank you Atlassian, and thank you Marketplace Partners for your thoughtful insight as well.

Regards,
Nick Muldoon, CEO, Easy Agile

[MattDoar]

Well put, Nick

[JacopoLanzoni1]

The proposal will require partners to develop and implement monetization strategies which are completely different from what they have had for years. The proposed tiers are new for many of us, and we will have to try, error and correct fast, depending on the reaction of customers to the proposed pricing. In order for this to be possible, we will need from the immediate start the reports available on the Atlassian Marketplace partner page to be extended in such a way that we can see sales and evaluations per licensing, per packaging and per pricing type.

I would like to stress a point: such monitoring features will need to be there from the very beginning. If the new Marketplace monetization strategies were launched without such visibility into the commercial data, it is likely that some partners will not be able to correct their initially imperfect pricing stance early enough, and this may damage irretrievably their products.

[aragot]

Will limits be imposed on pricing? For example, can the price be $1 per site user, or $5000 per agent as is usually the case in requirement management software?

Atlassian has often imposed limits, such as Cloud-vs-DC pricing, minimum per-user pricing, etc.

[ssidbury]

Thank you for sharing the details of the proposed app monetisation changes. While we appreciate the added flexibility these changes offer to customers, we are concerned about the increased complexity they introduce. The various pricing models and permutations in a complex customer landscape will require extensive explanation and may confuse customers.

For ScriptRunner, most of the proposed changes appear manageable, provided they remain optional as suggested. However, we foresee potential challenges with the user-based pricing model. For apps designed for Jira/Confluence end-users, a per-user pricing model is logical. However, for apps like ScriptRunner, which are intended for Jira/Confluence administrators, this model poses significant challenges.

Although only a small number of users (administrators) interact with the app directly, the automations and customisations they enable benefit all users of the Atlassian product. A per-user pricing model does not accurately reflect the value these apps provide to the entire user base, even if not all users interact with them directly.

Moreover, this approach is susceptible to misuse in the case of admin apps, where companies might license the app for a single, shared administration account utilised by multiple users. To reflect the value these apps deliver to the entire user base and maintain viable revenue for developers, each seat would likely need to be priced very high. This introduces new friction and messaging challenges, as it becomes difficult to explain to customers why admin apps have a significantly higher per-user cost compared to end-user apps.

Lastly, while adopting these new pricing models is not currently mandatory, vendors may find themselves with no other choice but to adopt them due to future market pressures, with significant impact on app revenue and business viability.

Thank you for considering our feedback.

[remie]

Hi @SarahAllen / @ibuchanan,

Considering that this topic might contain sensitive information about running your business on the Atlassian Marketplace, I think a lot of partners would feel more comfortable discussing this more openly if the RFC was moved to a private channel that falls under NDA.

I understand that traditionally RFCs are meant to be available to the wider Atlassian Developer Community, but I feel that this RFC is specifically targeting Marketplace Partners that wish to monetise their apps on the Atlassian Marketplace. As such, full transparency might not be a requirement here.

There is a great category in which this discussion would fit right in:
https://community.developer.atlassian.com/c/marketplace/running-your-business

Alternatively, it would also be an option to add an additional category for RFC’s that are considered confidential.

For those marketplace partners that do not have access to this category, you can request it here: Jira Service Management

Looking forward to hearing your thoughts.

Cheers,

Remie

[ibuchanan]

@remie,

With 20+ comments already, I don’t see a reason to move this RFC or to change its permissions. Across the extensibility standards I’ve helped build, we have made an explicit choice to keep consistent practices for the sake of simplicity. DX is not staffed to support case by case variations.

That said, I do understand why this is a special case. I believe that @SarahAllen and the Marketplace team are motivated to hear feedback, without having to be constrained by rigid rules. I’ll discuss with @SarahAllen to have her start a “side bar” channel. In general, I think RFCs have some “form” here in the community forums, but feedback is welcome through other channels, as long as it reaches the right people.

[osiebenmarck]

Hi @SarahAllen,
Thank you for the RFC and letting us peek into Atlassian’s thinking here.

As others have already said, separating JSM sounds like a great idea. Also, having paid app options for Compass and Bitbucket would be very welcome.

The current model is pretty easy to understand and while some customers do not look like it (“Why do I have to pay for X users if only Y admins use the app?”), it’s pretty predictable. But as far as all the other options are concerned, I have mixed feelings. Flexibility is generally good, but having too many options is going to be a nightmare for vendors, solution partners and customers. I’m just thinking of how any Solution Partner is going to create a quote that has multiple apps with different pricing models, especially when (as I understand it) apps will be able to offer multiple pricing options.

There is also one pricing model that especially did pique my interest and that’s usage based pricing. Of course, this type of pricing does away with all the predictability that customers enjoyed so far.
But if an app ran on a pay-per-use platform – something like AWS Lambda or maybe based on that – a vendor would be extremely tempted to use a pricing model that scales with the costs of that underlying platform.

[remie]

@ibuchanan thank you for considering a separate, more private thread.

Please note that my comment was triggered because of concerns raised by multiple vendors in separate communications channels. I’m simply making those concerns public.

With regard to the number of comments: yes, of course this is getting traction as this is an important topic for vendors. But it is not the quantity of the comments that should count for (any) RFC, but the quality. If vendors are holding back because they do not want to discuss their pricing strategy in public, we will end up with a sub-optimal solution.

Finally: although I’m not a securities lawyer, it feels odd to be publicly discussing pricing strategies between competitors in a marketplace.

[JensSchumacher1]

Adding my thoughts to the conversation.

First off, it’s great to see this area getting some well-deserved attention.

The introduction of advanced tiers, multi-instance licensing, usage-based, and agent-specific pricing are solid steps that I believe will really benefit customers, vendors, and solution partners alike.

That said, the shift to user-based licensing feels like it could bring some challenges. Since the marketplace has always been centered around instance-based pricing, this is a pretty big change.

I’m guessing part of the reason behind this move is the combination of Jira Work Management and Jira Software. From a customer’s perspective, it might feel off to pay for an app that primarily benefits engineering teams when legal or HR teams are also being charged under a per-user model.

Here are a couple of challenges I see:

Friction

It’s not entirely clear who will be responsible for managing access to user-based licensed apps. If this falls on administrators, it could add a lot of friction and administrative overhead, which might end up discouraging adoption. While solutions like spending limits exist, multiplying that complexity across multiple apps could have a real impact on usage and adoption.

Optionality

Even though it’s positioned as optional, in reality, customers are likely going to push for user-based pricing. They’ll naturally gravitate toward only paying for the people who actually use the app, which might create challenges for larger vendors. A pricing shift of this scale could have a significant impact on their business, especially without an easy way to test different pricing models.

Optics

Another thing to consider is how pricing might look to customers. For some apps, the cost could jump to $30 or more per user. When that gets compared to the price of Jira itself (even if the user counts don’t match up), it might create some hesitation around app adoption. Customers could start questioning why they’re paying more for an app than the platform itself, which could slow down overall adoption.

[ClaraRoder]

Thanks for sharing this and updating us on your plans. I had a few discussions with different internal teams about this RFC and would like to share our perspective:

• we like the idea of multi-instance licensing, it will be useful for enterprise customers
• JSM decoupled from Jira makes sense, together with a per agent pricing for JSM
• per user pricing - while we do have customers ask for that, none of our teams recall a situation where they lost a customer over user-based vs instance-based pricing. Even for niche products, we could always work out a solution with our customers. Changing to this model would require a massive overhaul of everyone’s pricing structure, especially for established products
• Would per user pricing change the app evaluation experience for customers? Could individual users trial apps and purchase them for just a single team or part of the company instead of the admin?
• Have in mind that usage based pricing will complicate the purchasing process for customers and solution partners. It will lead to an unforeseeable amount of additional administrative work for all license teams, as now all customers could receive additional monthly invoices for xx amount of additional workflows and checklists billed at 0.03 USD
• Adding on to the previous point: the selling process will already get more complicated for Solution Partners with the new packaging options; partners will need to know or look up with how many workflows* (*or any other usage-based feature) an app comes that now offer standard and advanced pricing and compare it with apps not using the different packaging plans but usage based pricing and ones that do both. The Marketplace will become less transparent and it will be harder to compare apps for customers.

Thanks for taking our feedback into account!

[ademoss]

Who from Atlassian is going to respond on this thread?
It’s been 12 days with no response, and it looks like SaraAllen is no longer a user on this forum? (At least the account is suspended)

[dmorrow]

I will ask around to find a replacement.

[nparamonova]

Thank you for the information regarding potential changes in pricing models. Here are some thoughts on the subject.

The Multi-instance Licensing could be beneficial if fully technically supported in terms of billing on the Atlassian side. This would allow marketplace partners to align with what Atlassian offers to clients. In my opinion, it’s reasonable to provide the same monetization models for parent products and marketplace apps. This approach simplifies calculations, explanations, and understanding. However, calculating new prices without complete information about utilizing of such licenses for parent products may be challenging for marketplace partners. Also, from the customers’/administrators perspective, tracking and managing multiple parent products and apps with varying user tiers and usage across different instances may be difficult.

Cons about other pricing models:

• The technical implementation of the user or usage-based models will be challenging during both the development and operational stages: Who counts the users/events? How are they counted? Is anything overlooked? Who is considered a user, and what counts as an event? E.g., if one user configures a tool but 100 people benefit from viewing the result — who is the user and what is the event?
• These models would require constant recalculations, potentially leading to frequent upgrades and downgrades.
• This adds complexity for customers and partners in selecting and comparing apps and in communications.

Thank you for considering the feedback.

[Alexandr]

Our company as a tiny vendor does not see a big value in the new “flexible licensing”.
One good thing is to separate JSD agents from other users.

[HarshDhaka]

@ademoss I will be responding to all comments by EOW.

[jaroslaw.solecki]

Thank you for sharing the details of the proposed app monetization changes. While we understand the goal of providing more flexibility to customers, we would like to highlight several concerns that could pose challenges for both vendors and customers. Below are the key points that we believe warrant further consideration:

1. JSM apps are often user-oriented, rather than agent-focused. In this case, pricing per agent would be similar to pricing per admin for Jira. Apps primarily used by agents but benefiting entire organizations are difficult to price fairly on a per-agent basis. While fewer agents than users interact directly with these apps, the value they generate impacts the entire organization.
2. Introducing usage-based pricing may lead to complex billing scenarios where customers receive multiple monthly invoices for additional usage. This could increase the administrative burden for both customers and solution partners. Managing access: If app access is managed by administrators under a user-based model, it could create friction and increase administrative workload, potentially deterring adoption.
3. Vendors, particularly those with well-established apps, may face significant disruptions in transitioning to the new pricing models. The risk of revenue loss or business instability is high without a clear path to test these new models in a controlled manner.
4. With added complexity in pricing and administration, both vendors and solution partners may see an increase in the time required to close deals, potentially leading to slower revenue growth and reduced profitability.
5. 1. Six months is a very short period to prepare new pricing models and calculate the impact and risks they might involve and to adjust to the new business model. Especially for vendors with extensive product portfolios where in each app different pricing models could be better.
6. Are there any plans to introduce (and align with the changes recommended in this RFC) any new initiatives strictly implemented in order to drive revenues and further monetization for the vendors (and of course Atlassian)?

The RFC gives just some assumptions but there is a lack of details which raises some of our questions:

1. Will it be possible to test a new approach for pricing on a small group of existing or new customers? If it is all or nothing the risk to experiment on a living organism is too high from our perspective.
2. For usage-based pricing, will customers be able to set a limit on their monthly payments?
3. Are there any conditions on how often the vendor changes the pricing model (assuming the partner or customer wants it) or when the price changes effectively? Will customers need to accept the change once the pricing has changed? When will the change apply, after confirmation? What if they refuse?
4. Can a vendor use multiple types of licenses or choose one? Can vendors combine pricing methods and charge customers for both users and usage?
5. How will the changes be implemented if a customer buys a license for a limited number of users? How will in-Jira communication with such a user look like?
6. If licensing is delegated to vendors and their operating costs increase, will Atlassian’s fee be reduced? What if any countermeasures Atlassian plans to provide partners to drive additional revenue in case all the new possibilities of pricing models will decrease vendors’ ARR?
7. Does per-user pricing affect end-users who benefit from an app’s effects but don’t directly use it? A lot of apps are configured and directly used by an admin, but they affect the work of many end-users.
8. Will there be the ability to set different prices for agents and users for apps compatible with Software and JSM?

While we acknowledge the potential benefits of monetization changes, we recommend careful consideration of the challenges they introduce. We suggest exploring ways to pilot the new pricing models or offer them gradually to avoid overwhelming both vendors and customers with the complexity of the new system. Please consider us if there is an early access program, so we can collaborate with you further on these changes.

[david]

A bunch of premium features for Confluence and Jira are only available to admins.

Does this mean that we can buy the premium parts of these product just for one or two users? That sounds great as it will bring the cost of the product right down.

Also, being able to have unlimited whiteboards, or databases, or access to analytics for one or two users might be helpful. Is this the way that Atlassian are going with their pricing structure?

[emil]

Feedback from Refined:

• We like the concept of App Editions.
• Agree that JSM decoupling and multi-instance licensing make sense.
• We are not in favor of per-user-based licensing, as it would add unnecessary complexity to the purchasing process.
• Our primary concern is that these suggestions represent a lot of changes happening simultaneously.
• In our view, the App Editions concept would have the most significant impact on the ecosystem. Maybe start there?

[oliver.straesser]

Thank you for the thoughtful RFC on Marketplace monetization strategies. I have a few clarifications regarding the proposed changes:

1. For user-based licensing, will the billing period be monthly or annual?
2. Will customers be able to choose between user tiers and user-based pricing, similar to Atlassian?
3. How will user counts be determined—by permissions or actual app usage?
4. For JSM pricing, will it apply only to JSM users, or will customers be able to acquire the app for the entire Jira user base?

To sum up, Will it be precisely the same approach as for the main product, or will it be for us vendors to stick with one license model, which would be different from Atlassian?