Thanks for the response here Sean, we appreciate that Atlassian is owning that the technical bones of forge are not on target relative to the business requirements. I hope we can now get an additional update on the revenue portion from @ChrisHemphill1 et al. Atlassian taking more while not meeting it’s own obligations is not a good look from a partnership perspective.
12 Likes
Just restating what others have already said…
Now that Atlassian has confirmed that Forge will not be ready in time for the January 2026 deadline, Atlassian business needs to set a more realistic deadline for marketplace “partners” rather than further punish and further demoralise them based on an arbitrary decision.
8 Likes
I appreciate the candor from @JuliaDaehne and @SeanBourke regarding the state of Forge feature development. Julia and the rest of her team are handling the issue of dynamic modules exactly as I would have hoped: which is to say, not rushing and taking their time to do it right.
However, the above promise to “ensure we bring the right response back to you and the community” remains unfulfilled from my point of view. The tech data from Sean and Julia is helpful, but as I wrote a week ago, the tech stuff was not even the point of this post.
To be more direct, let me repeat the part of the original post that remains unanswered. If Atlassian chooses to answer it, I believe this data would need to come from your team and not the tech people:
Is Atlassian planning to address this part of the question? Even if that cannot happen right now for whatever messaging/legal/etc reasons, telling us that some sort of answer is in the works would go a long way to build trust. Otherwise, this thread currently reads as “yes, we acknowledge that you will have 30 days max to build a feature that we will ship just before the holiday break, and we will probably remain silent about penalizing your revenue for something that is out of your control”.
I have also previously opined about Atlassian’s use of carrots and sticks to get people to move to Forge. I also infer that Atlassian has a problem with Forge adoption (namely, that not enough existing apps are migrating to it). I further imagine that this Connect revenue share increase was intended to juice those migration numbers.
In case it was not obvious, I wanted to add that Atlassian has now given vendors a great carrot to move to Forge: the 0% revenue share on the first $1M of Forge sales. This is a great motivator, and believe me, as soon as the platform is stable and capable of supporting my app, I will move it. It also provides great motivation to test out Forge modules and provide feedback to Sean and team.
That is already a lot of motivation, so raising the Connect revenue share before the platform is ready just adds insult to injury, rather than increasing motivation.
19 Likes
Hello all, appreciate your patience on this thread. Thanks to @SeanBourke for chiming in from the forge point of view. We are taking several of these requests into consideration, both public and private, and we have decided to not allow any exceptions at this point.
Here is a bit more detail on our rational
-
Our ecosystem is large and diverse, which presents challenges as we phase out Connect. The large majority of partners are able to move to Forge today, but some partners may not have complete parity by December 31.
-
We are balancing several criteria as we make decisions: fairness and partner needs; and continuing forward momentum. Sometimes that does mean making hard decisions that have a financial impact on partners who are blocked. We are working to unblock those partners as quickly as possible and expect to deliver key features by the end of the year or in early 2026.
-
Partners who won’t be on Forge on January 1 have two options: absorbing the cost of the higher take rate for a short period of time, or passing costs on to customers through higher prices. We understand it’s not an easy decision for partners.
Appreciate your dedication to the ecosystem and your feedback above.
This is not true for us. I have also heard the same from most other vendors with whom I have discussed this topic. I am happy to admit that my anecdotal evidence is very limited compared to the scope of the entire Marketplace. Can you share how Atlassian has made this determination?
12 Likes
Not true for us.
We particularly need:
- FRGE-729 OAuth asApp – not scheduled until at least Q4 2025, or maybe later
- FRGE-1145 Anonymous access for Confluence
Probably some others too.
8 Likes
Can you share more information on this? While we are able to move to Forge soon, this would mean to loose several features of our apps.
Currently we seem to have the options:
- Take a financial hit or increase pricing
- Reduce features of our apps
when we move to Forge. Both options are not healthy for the Atlassian ecosystem.
6 Likes
It does not sound very convincing, considering that many of Atlassian own apps are still running on Connect, including one of the largest apps “GitHub for Atlassian”.
And the reluctance to adopt Forge as a first-class citizen within the Atlassian product development to the same degree as P2 in Data Center also does not make a good case for the future of the platform.
And of course there is no contractual security for the vendors that Atlassian one day won’t decide to implement the same functionality natively, while the vendors of established apps in the same niche are wasting months of even years migrating to Forge and possibly cutting the useful functionality due to the platform limitations and unrealistic deadlines.
A lot of trust and good faith within the ecosystem was wiped by Atlassian’s decisions in the recent years, but it may be not too late to start rebuilding it.
12 Likes
Do you really though?
Continually gaslighting partners by claiming most can & should move to Forge, despite the obvious parity gaps from Connect and generally negative sentiment towards Forge by many partners; it doesn’t sound at all like you appreciate our dedication to the ecosystem.
Quite the opposite, in fact.
7 Likes
Forge Product Team: “we won’t have parity by Jan 1st, we’re not involved in the revenue penalty decision, our team is against it”
Marketplace Partners: “there’s no parity, we can’t migrate, the timeline is not feasible, it’s unfair to punish our bottom line here”
Marketplace Partnerships Team: “we admit there won’t be parity by the deadline and many partners won’t be able to migrate, but lol that’s a you problem, get rekt mate”
What in the dysfunctional hell is happening here?
Stating that our options are to either absorb the cost or pass it onto customers is simply stating that Atlassian in this instance will happily f*ck both the partners and the customers.
How is that aligned to the company’s values? Core Values | Atlassian
16 Likes
@ChrisHemphill1 are you aware that they haven’t even sorted out the fundamentals of versioning yet on Forge: RFC-106: Future of Forge versioning - Permissions
That RFC is very much in the ideas stage. I wouldn’t expect it to rollout until late into 2026.
Versioning is so cooked that 90-99% of installs on my Forge apps are running broken/outdated versions (that Atlassian broke!) with no means to fix that mess at this moment.
Anyone who migrates their Connect app to Forge will stare down that same abyss.
If you force this mass migration before that is resolved you will have opened an operational and security nightmare where the majority of all marketplace app installs are running outdated app versions.
Not to mention the missed targets Forge will have out of the gate as customers uninstall broken apps due to this issue.
6 Likes
The message is a bit cryptic, but I infer from it that there is no good reason to penalize partners stuck on Connect, other than to make use of the opportunity.
For the record, this is not true for us either (assuming we are talking about a move to Forge that avoids the Connect penalty, not Connect on Forge).
8 Likes
I agree with this sentiment. We would love to see Atlassian prove their commitment to Forge by embracing it more internally. Only then will we see all of the little wrinkles app developers face in Forge getting ironed out.
7 Likes
Not true for us, either.
In fact, I think that those apps with highest installation counts are the ones that can’t migrate to Forge. (Or can, but are near impossible and time-consuming to meet these deadlines.)
I am saying It because for these apps the followings are typically true:
- Their have been improved over a long period of time, adding features all the time, therefore complexity is the highest.
- Their Connect implementation may rely the greatest number of services not currently available on Forge (in our case: queue, lambda, timeseries database, just to name a few).
- They probably started on Server, then DC, then Connect, which means a codebase with 10+ year long legacy.
- They have the largest number of customers, so dropping a feature customers love will be difficult to explain (–> frustration, churn).
- …
8 Likes
Not true for us. Could the real forge movers please stand up?
9 Likes
To add some numbers to this, I went through and did a quick scan of per app blockers. Our most simple app has 3 blockers. Our most complex app has 7 blockers. We do not expect any apps to be fully unblocked by Jan 1. We’re still actively adopting Connect on Forge and trying to get as close as possible. We are working to play ball as best as we can.
7 Likes
Hi @ChrisHemphill1 – First, thank you for directly addressing the core topic of this thread (the financial penalties). Honestly, I was expecting Atlassian to ghost us again, and so I appreciate that someone (you) stepped up to answer. To be clear, I don’t like the message, but I appreciate that you delivered it anyway.
Second, I understand the conundrum Atlassian is facing. You (Atlassian) need to move the ecosystem forward, away from Connect and towards Forge. And this requires “motivating” app vendors that aren’t moving on their own accord to start moving. But it’s hard to pressure those app vendors without also harming the vendors that are trying to move but are blocked. Thus, you have a dilemma.
That leads to my third point…
…I’d like to propose a constructive solution to Atlassian’s dilemma. I believe there is a way to pressure the vendors who aren’t yet moving, while minimizing the impact on the vendors who are more cooperative, yet who are blocked by Forge’s insufficient parity with Connect.
Most importantly, I believe you can do this in a way that is transparent and based on objective data:
- Instead of talking about the “large majority of partners”, let’s talk about the top 100 apps in the Marketplace based on the number of installs. This data sample is both objective and more representative of the impact of Forge migrations on the overall ecosystem.
- Looking at the top 100 Marketplace apps, here is the current platform mix (data source):
- Connect: 44 apps
- Connect on Forge: 47 apps
- Forge: 9 apps
From this objective data, we can draw a few conclusions:
- There is a lot more work to do. Only 9% of the top apps are “pure” Forge apps.
- The majority of “top vendors” have visibly at least started a migration to Forge. More than half (56%) of the top apps use a Forge manifest.
- A still significant number of the top apps (44%) have not visibly prepared for Migration Phase Two.
- Note: Of course, this doesn’t mean they haven’t started; just that we can’t objectively see that they have.
So basically, this data supports both sides of the ongoing debate: 1) The community is correct that the majority of vendors are trying to migrate, and 2) Atlassian is correct that not enough vendors are (visibly) trying.
Proposed solution:
- For Connect-only apps: Continue the revenue sharing penalties as planned.
- For Connect on Forge apps:
- On January 1, 2026, treat these apps as Forge apps, and apply a 16% revenue share (instead of 20%).
- On July 1, 2026, set a threshold for the percentage of modules that must be Forge modules for the app to be considered a Forge app. Atlassian can probably set a high bar for this threshold.
- If an app fails the threshold test, treat it as a Connect app and apply the 25% revenue share.
- If an app passes the threshold test, treat it as a Forge app and apply the 17% revenue share.
- When the Forge Team removes a sufficient number of migration blockers, then announce that all Connect on Forge apps will be treated as Connect-only apps.
Intended benefits:
- Atlassian will create forward momentum. You will pressure the 44% of top apps (plus however many others) to begin the Forge migration process. This will be real progress.
- Atlassian will not immediately penalize apps that are blocked by feature parity. This will start to rebuild trust between Atlassian and its vendors.
- This solution would be based on readily accessible data, thus avoiding the complexity needed to create app-specific exemptions.
- Note: I’m assuming that if Siebert can report on this data, Atlassian can, too.
- This buys the Forge team the time they need to remove blockers. If Atlassian’s messaging has been sincere, then most blockers should be removed by July 1 of next year.
- Edit: This will protect customers from the impact of vendors either raising prices (more than typical) or removing features. So, this brings us closer to a win-win-win between Atlassian, vendors, and customers.
I know this solution is imperfect and can be made better. But hopefully it moves the conversation in a more constructive direction. (And hopefully Atlassian remains engaged!)
Thank you!
22 Likes
We have started porting out apps to Forge, but we have not released on Connect-on-Forge.
The reason is the version and upgrade and dependency chaos from a vendor perspective. Due to the phased and (for us) unpredictable delivery of Forge features it makes sense to start building, but not releasing a Connect-on-Forge app. I assume that other vendors reason similarly.
5 Likes
I want to make sure I’ve understood the options. Assuming I am able to migrate to Forge by the new year, I get charged a variable cost for consumption as a separate bill. If I don’t, I lose a bit of revenue share, but it’s a fixed known percentage and comes out of my revenue share? I can always increase the price of app.
3 Likes
A third option (and what I suspect most will do) is use Forge Remote. You will then be a Forge app (and benefit from improved revenue share) but can have your backend under your control (and not use the Forge compute modules, and therefore won’t be charged for them). Note this means you won’t have a Runs on Atlassian app, since there will be egress.
To add to Arron’s analysis of the top 100 apps, out of the 9 fully Forge apps (which would benefit from the improved revenue share) only 3 are RoA. And of the Connect on Forge apps, many of them are using backends hosted elsewhere.
3 Likes