Forge pricing model

Forge
1

Hej Atlassian,

I’ve been asked to “Help refine Atlassian’s developer platform pricing mode” and I noticed that there is a bit of a bias in the survey, in a sense that it seems that you are focussed on getting feedback for a revenue-share based pricing strategy for Forge and do not seem to be exploring any other pricing strategy.

To be honest, it feels rather convoluted to combine the use of Forge with the existing revenue share program.

As I’ve always understood it, the revenue share model was meant to pay for payment handling and the investments in MPAC and supporting developers. This is a fixed % for every vendor, regardless of how popular the app is. It is not related to usage.

With Forge, like with any other hosting platform (like AWS or GCP), it seems a bit weird to relate this to % of revenue, as this is about resource consumption. The cost of using a hosting platform is directly related to the use of the app as well as the app architecture.

For instance, for our embedded apps, our YTD revenue is ~40K. But these are static apps that consist of only HTML and JS/CSS. Hosting them on GCP firebase cost is close to nothing (<10$ per month).

Yet for our more complex apps, like Figma for Jira and Figma for Confluence, we have chosen to use a more complex infrastructure with aggressive caching to improve user experience. For those apps, our hosting costs are ~10% of revenue.

Having a Forge pricing model that is based on revenue share would make it very unfair for both scenario’s as we will overpay on apps that use nearly no resources and underpay on more complex apps.

And this even excludes scenario’s like Forge Remote, which will almost be required for complex apps as Atlassian will not be able to provide all compute resources on the Forge platform. Which means that we will still be paying external parties (AWS / GCP) for our apps in addition to paying for Forge.

I would strongly suggestion for Atlassian to reconsider the proposed Forge pricing strategy and come up with a scenario in which the current revenue share model is not applied to a usage-based platform like Forge.

Otherwise, I would not be surprised if Connect will continue to be popular amongst Marketplace Partners. Unless you are going to use negative pricing incentives on Connect to force us to migrate to Forge, but I’m really hoping that you’re not going to turn into that type of company :wink:

Cheers,

Remie

10 Likes
2

I second this opinion. This survey was overcomplicated and started from the assumption that there would be revenue share in any case. I don’t think my answers in that survey reflect my opinion about this topic.

The survey is unclear about the revenue share part and why it is there. What does it have to do with Forge-specific pricing?

Our hosting costs are small relative to revenue. So, for us, only a minimal increase from the current revenue share numbers (1-2%) would make sense as a Forge-specific charge.

As mentioned above, hosting cost/usage can vary by app/Marketplace Partner, which suggests that usage-based cost may seem the most logical option.

7 Likes
3

From another point of view, vendors are already paying a significant amount of cash in terms of revenue share. I imagine it is unlikely that this information can be made public, but it would be interesting to understand how much of this share (15% to 25%) is actually spent on programs such as MPAC and developer support. With $4 billion in lifetime Marketplace sales, that would leave an Atlassian revenue share of $600 million to $1 billion. Subtracting 3% paid to the CC processors, I believe that still yields $500-900 million (lifetime) remaining within Atlassian.

Are the costs to run MPAC and dev support that high? In other words, is the revenue share generating free-flowing revenue for the rest of Atlassian, or are these programs still cost centers even after the revenue share?

My guess is that this is generating free-flowing revenue (but feel free to change my mind!).

From that point of view, it seems like Forge should be already “included” in the existing revenue share (or at least included with reasonable usage limits). I understand the desire for a pricing differential, but since Connect is no longer receiving any meaningful features (and should thus be cheaper for Atlassian to run), how about discounting the Connect revenue share and leaving the Forge revenue share as-is?

Although I do not suspect that this idea will be seriously entertained (there are shareholders who want to see YoY revenue growth, after all), I think it is still a good thought exercise.

Regardless, since Atlassian is going to charge for Forge, I am not in favor of a revenue-based payment system because various apps have widely varying resource requirements (as already noted by commenters above). I imagine that the proposed plan would create a certain amount of simplicity within the existing vendor payment systems, but I think Atlassian does need to bite the bullet here and build out a resource-based billing system, even though doing so would be complicated.

5 Likes
4

Hi all. Thanks for your feedback.

We are trying to think broadly about the total cost of ownership for building a Forge app in the marketplace, not just hosting costs. The survey is therefore testing a few different models, including changes to the existing revenue share arrangement on Marketplace: (1) A revenue share model (ie. the marketplace take rate is adjusted to account for Forge hosting costs), (2) a revenue share model with a gross revenue threshold (ie. you don’t pay anything until the app has generated $x in total lifetime revenue), and (3) existing revenue share + a consumption based model (ie. pay for what you use).

I’m sorry that you’ve perceived any bias in this survey - that’s not the case. We are genuinely seeking feedback on each of these proposed models and the components within them. Receiving strong negative feedback on any of the revenue-based pricing models is a potential outcome of this research.

The survey is only a single data-point and will be evaluated alongside other sources of feedback.

There is some randomness in the survey (each participant may receive a different set of options to evaluate), so it’s possible you got a particular sample that overly indexed on the revenue sharing models.

Happy to chat if you have further concerns.
Joe

6 Likes
5

Thanks for clarifying @HeyJoe

What makes it confusing to me is that, as I mentioned earlier, the revenue sharing model has historically been associated with the cost of running the marketplace program.

I’ve seen suggestions in the survey in which developers would keep 100% of revenue until an app reaches a $2M ARR threshold. As there are only relatively few apps (not vendors, but apps) that achieve this, how would this impact the marketplace program?

For me it is difficult to fully grasp that it seems that in Atlassian current line of thinking the cost of a variable resource usage based hosting platform (forge) is combined with what historically has been a fixed fee of running business on the Atlassian Marketplace.

I would be a strong proponent of a pricing model in which there is a fixed revenue share % for all apps (like with Connect) and a usage based pricing model for the hosting platform. This would also make Forge better comparable to other PaaS/IaaS offerings.

Combining the cost of Forge with revenue share creates a black box which will make it even harder for Marketplace Partners to understand what Atlassian does with the marketplace revenue (which, as you can see from @scott.dudley reply is already difficult as it is now)

3 Likes
6

Some of the content in the survey is variable. You may have seen a choice for a $2M threshold, others would have seen a much lower one. Also, to clarify, the survey should have been asking about a lifetime revenue threshold, not an annual rate.

I would be a strong proponent of a pricing model in which there is a fixed revenue share % for all apps (like with Connect) and a usage based pricing model for the hosting platform. This would also make Forge better comparable to other PaaS/IaaS offerings.

Message received loud and clear :+1: :slight_smile:

2 Likes