Forge delivery vs. the upcoming Atlassian Connect penalty

Forge
1

Hi @ChrisHemphill1

I am starting a new thread because the earlier one was auto-closed.

You wrote:

We’ve heard your concerns about the effects of some decisions and changes, and we’re actively working to address these issues

You also wrote (emphasis added by me):

As of today, partners have nearly 7 months before revenue share updates take effect on January 1. The updates were announced ahead of the usual 6 month window to give partners as much time as possible to choose the path that makes the most sense for them and complete any necessary development work.

I previously raised the issue about the Forge development delivery timeline not being in sync with other Atlassian business-level deadlines. This worry now also extends to the upcoming 5% (and soon to be 10%) revenue penalty that will be applied to Atlassian Connect apps.

Among other items in the “previously” link from above, I wrote this:

Vendors need time to build and test and deploy the changes required to work with new Atlassian implementations. If the deadline is 2026-12-31 but the final changes are shipped on 2026-12-30, vendors cannot turn that around on a dime.

While I was not hoping to be prescient in this matter, I received a notification today stating that a feature that my current Connect app currently uses, dynamic modules, just had its target ship date moved from 2025-09-30 to somewhere between 2025-12-01 and 2025-12-31. The Atlassian Connect penalty starts on 2026-01-01.

So, I do not have “nearly 7 months” to make my app work completely with Forge. Even assuming that no other portions of the features are delayed, I have somewhere between 1 and 30 days (of which a significant portion is swallowed by the holiday break). Past trends suggest that Atlassian is unlikely to publish the documentation until the feature is shipped, so I will also be shooting in the dark until then. (For example, will the feature even cover my existing use case? The existing RFC suggests a major architectural change from the Connect way of doing things, so even this part is unclear.)

To be blunt, this interval is insufficient for professional software development.

Has Atlassian really heard [our] concerns about the effects of these decisions? As I wrote in the “previously” link above, Atlassian is using an agile process for Forge development, but a waterfall process for business decisions (such as the pricing changes)…and these two are not working well together.

Is Atlassian even considering revising its decision to penalize Connect apps on January 1, or is this a “we heard you…but we are sticking to our guns”? If this is a foregone conclusion and vendors want to be able to adjust prices to try to avoid a revenue drop, we need to know right now. I am not sure if you are aware that it takes five months to fully push through a Marketplace app pricing change (pricing submitted today + 60 days grandfathering + 90 day quote duration).

In other words, if you want your app to be fully on the new pricing by the time this revenue change hits, new pricing needs to be submitted this Thursday.

I understand that Atlassian wants to move people to Forge. but penalizing vendors who cannot move to Forge (due to Atlassian’s moving delivery deadlines) is not the way.

If you are going to do this anyway, I am sure that vendors would appreciate a note saying something along the lines of: “we know that this is going to hurt some of you, but we need to enforce it anyway in order to move the ecosystem along, and we have our [KPIs/metrics/whatever] that we cannot meet unless we try to move everyone along [or whatever the driver might be], so it is a hard decision that is unfortunate but necessary”. Or maybe you are still working on some sort of response but you cannot write it out yet for internal/legal/whatever reasons. In this case, a “we are working on something and we hope to get back to you on 2025-yy-zz” is still better than nothing.

The alternative (continuing to repeat “we hear you”, but being otherwise silent in response) does not lead the reader to believe that the “we hear you” is particularly sincere, which makes me feel like the DFTC/!BS culture is continuing to fray from the point of view of the vendor.

72 Likes
2

Absolutely.

I’m waiting for OAuth asApp it is ever delayed and keeps getting pushed back. I doubt it will be finished, or even started this year.

The deadline for moving to forge is, as everyone outside Atlassian is aware, just absurd.

6 Likes
3

Scott, Appreciate the note. You bring up quite a few good points. Let me check with the team on the pushing of that feature and come back to you - as you pointed out, its not just me on the other end and I want to ensure we bring the right response back to you and the community.

David, I see yours as well and will ping the same folks on those.

1 Like
4

Hi Chris,

I really appreciate the response. I should probably add that although the dynamic modules are one item I am waiting on, they are not the only item either.

The dynamic modules feature is just an easy call-out because it happens to be the one that Atlassian has now more-or-less confirmed as not being shipped soon enough.

The other features may or may not be shipped soon enough (vendors don’t have that level of visibility and not all your plans are made public), but I do not yet have enough certainty to raise a flag for those yet…other than to say that there are now only five months to go for some of these features. And some of these are, to my app, even more important than dynamic modules.

I am also writing this from the perspective of only one small vendor. I have seen plenty of other vendors complaining about missing items on their to-do list.

All of this is to say that while I certainly would not object to getting more information about my specific issues, that was not really my point: I am not complaining about the pace of development (the team appears to be working hard and I am sure we are getting max effort), but rather, I was asking what can be done about the business-side deadlines that appear to be floating along merrily, seemingly independent of the development status.

19 Likes
5

Exactly what we are experiencing, too.

Many partners are waiting for Forge features while the countdown is ticking away, and there is little to no acknowledgment from Atlassian that they recognize the problem.

To be more specific, I am listing the three major items currently blocking our progress. But as mentioned, the point is that many partners are waiting for different features.

  • FRGE-729, OAuth2 asApp, as mentioned by David above
  • FRGE-1661, JSM display conditions, I was told a month ago that there is currently no team working on JSM extensibility
  • What happend to Forge Cache? The question was asked in the last Forge webinar, but remained unanswered
15 Likes
6

Back at the start of of 2025, we responded to Atlassian’s survey with a list of issues & blockers, and were told to watch/vote on the related FRGE tickets, which we did.

From a total of 11 x FRGE tickets (some hard blockers, some just annoyances), want to guess how many have progressed to resolved?

Precisely zero. In 7 months, not a single one has been closed. All the while, the countdown to a significant financial penalty marches on.

At this point, there is no chance we will make the deadline, through no fault of our own.

Why should we continue to participate in an ecosystem, and share 30% of our revenue, with an organisation that treats its partners like this?

23 Likes
7

Same story here. To name just a few issues (of many):

During the migration process, we consistently encounter issues and identify missing features that require ad-hoc workarounds. I agree there appears to be a disconnect between business decisions and the platform’s development progress and maturity.

9 Likes
8

Considering that webhooks aren’t available in Forge, dynamic modules are the only way to have a Forge app respond to events with some sort of filtering.
Without them, the only alternative is to have a global listener to issue_updated, which is going to be triggered millions of times on large instances.
This would be extremely costly in terms of runtime pricing, and I wouldn’t be surprised if it could even cause platform instability due to the sheer number of triggers.
I don’t think that anybody would want that.

Even if this EAP is actually delivered in December, asking developers to implement those changes – which might not be final and can be subject to a shorter deprecation notice (it’s an EAP after all) – in such a short time is basically impossible, unless you’re willing to compromise the end-user experience with rushed code and barely any testing.

I’m fine with Connect going away and moving everything to Forge, and we’re doing everything we can to get it done, even if it means that we’re rebuilding apps that were working just fine instead of adding new features… however, I gotta say that Atlassian isn’t making it easy.

This is just one example, there are other blockers that many other developers have mentioned in this and other threads.
I don’t think that Atlassians are sitting idle and twiddling their thumbs either, but if the initial timeline is not achievable, for the sake of the marketplace community as a whole, there should be some clarity and adjustments should be made accordingly, otherwise the pricing updates are simply going to be “If your app is complex, you’re gonna pay more, if you have a simple add-on that can be trivially replaced or get sherlocked, you keep paying the same fees” which is not a compelling value proposition.

18 Likes
9

There’s no support for the revenue penalty from anyone I’ve ever spoken to internally.

The Forge product team do not support it. Go ask them!

And there’s undoubtedly no support for it at all from the developer ecosystem.

Time to drop it @ChrisHemphill1. It’s doing far more harm than good.

Reintroduce it in the future when all migration blockers are long passed.

10 Likes
10

I think this is very good point made by Scott - I’m guessing almost every (commercial) vendor on the Marketplace now got the message that Atlassian is serious about transitioning everyone to Forge and will be taking steps to migrate - and, internally or communicated, already has a list of blockers or issues (we do, here, here). I do think it’s important to distinguish actual, hard blockers which prevent from migrating, and issues where just a bigger investment is necessary or retirement of a minor feature might be acceptable.

What I think would help is commitment from the Forge team to use the next 6-12 month to unblock as many vendors as possible as possible to move to Forge, since the looming revenue share change will impact all Marketplace vendors in a very painful way. It does not feel like the time to built more custom Forge services (like containers), when there’s still feature parity gaps to Connect, with no workaround or alternative implementation. It feels like we are at mercy to shout our FRGE tickets into a community post to get them prioritized, but I’d really appreciate a pro-active communication from the Forge team on this.

16 Likes
11

The problem here is that there is no objective reason for such narrow deadline. Both the revenue share change and connect eol are in full control of Atlassian. And it’s completely up to Atlassian to align the timeline for revenue penalty and connect eol with the realistic delivery timeline for feature-complete and stable platform instead of rushing everyone to achieve the impossible before the artificially imposed deadline. And these misaligned and impossible deadlines are also very likely taking their toll on the Atlassian staff as well.

10 Likes
12

Another problem is that some of the Forge features that have already been developed differ from the Connect version in important aspects.

One example of this is Confluence Product Event Parity (ROADMAP-98). Unlike with Connect, one event is not sent in some cases (for restricted content) or data is missing in the event payload.

Hopefully, issues like these will be addressed before the feature enters GA (it’s currently in preview), but it adds to the uncertainty whether we will be able to implement the features we need in our apps.

The Connect deprecation reminds me of the Confluence REST API deprecation, where Atlassian severerly underestimated the effort needed to provide an adequate replacement and the work required by Marketplace partners to migrate their apps. In the end, the REST API deprecation had to be postponed six times (one and a half years in total) due to unrealistic deadlines.

9 Likes
13

@ChrisHemphill1 we keep telling Atlassian that Forge isn’t ready yet for a big Connect migration (see here and here) and it looks like our fears are coming true.

We also have hard blockers for migrating only our top 3 apps (1, 2, 3, 4). Also, major parts within Forge are unstable with EAP and Preview notices everywhere. We discover new Forge bugs and inconsistencies with Connect every week (example 1 and 2 just for Jira post-functions) and there are important parts that don’t seem to scale for large apps. We can’t even see production logs and would get charged for > 300 GB of system logs without being able to influence those system logs.

We’ll probably have to drop some features for our apps in order to convert them to Forge by the end of 2025. The alternative of getting 4% (and later 8%) less revenue share is too uncertain, since we won’t have any guarantee when those missing Forge features will be delivered by Atlassian.

Please reconsider your timeline and allow your own teams more time to make Forge a platform that developers want to migrate to and aren’t being pushed on with so many hard compromises.

31 Likes
14

Specifically about Forge dynamic modules (cc @scott.dudley @PaoloCampanelli): as you have noticed with 2 RFCs on the topic there are different options on the table and we are still assessing best technical design and realistic delivery timelines.
As a Sep delivery became increasingly unlikely I have moved the timeline to last quarter of the year - which is reflected as Dec in Forge public roadmap. I will provide further updates to the timeline as soon as it becomes available.
Rest assured that this is being worked on with high priority. We are aware of the importance of this feature for partners looking to move their Connect dynamic module or webhook set ups to Forge.

3 Likes
15

I’m just want to re-confirm the same concerns written here by many app partners:

We are waiting on serveral Forge features to migrate some of our apps. Even if these features are ready, lets say by magic in October: Then it is still unlikely that we get the app moved completely off Connect in Q1 2026.
We have to start porting, re-architecting and discover all the details where the previous assumptions do not hold anymore. That takes a long time to grind down.
We are guaranteed to be hit by the ‘not-yet-on-Forge’ punishment.

12 Likes
16

Hi @ChrisHemphill1 and @JuliaDaehne – I’d like to reiterate a concern that has been expressed many (countless?) times already. This concern is directed at Atlassian leadership collectively, not to you personally.

Julia, you shared:

This sort of decision makes perfect sense to probably every developer in this forum. We’re an agile community, and we understand agile planning and agile decision-making.

And that’s actually the frustration many vendors are expressing. Vendors are simply asking for the same privilege that Forge development teams are exercising…the same privilege you exercised when you necessarily updated your roadmap based on changing realities…the privilege to engage in agile planning without being penalized.

What do I mean?

Some (perhaps many) vendors have a dependency on your team to complete their migration to Forge. You updated your roadmap to reflect the reality that those dependencies will be delivered later than initially expected.

That’s perfectly reasonable.

What’s unreasonable is that Atlassian leadership has yet to acknowledge this shifting roadmap and change the start date for financially penalizing apps that are not fully migrated to Forge.

In short: You updated your team’s roadmap based on changing realities → This caused a “change in reality” for the vendor community → But vendors cannot update their roadmaps accordingly (without facing financial penalties or removing established features).

This isn’t about specific features being delayed. This is about Atlassian’s business managers not managing the Forge rollout using the same agile principles that Atlassian’s technical managers are employing.

Or in the words of the OP:

I hope you do not consider this matter resolved.

13 Likes
17

Thanks everyone for your feedback and we hear you about Forge features. We’re steadfast in our goals to continue delivering key capabilities on the Forge platform and have made significant progress is recent months with the release of dozens of features including offline user impersonation, Confluence events, content properties and more.

Our Forge Roadmap details more items which are in active development or exploration, including (but not limited too) display conditions for JSM and Confluence, user impersonation for JSM users, CQL for Forge macros, anonymous users in Confluence and more.

With that said, I want to acknowledge that we won’t have everything by the end of this calendar year. We continue to strive to delivering use case equivalence between our platforms (where appropriate) and will continue key features. The feedback from the community has been instrumental in helping us shape our priorities, delivering key capabilities which have unblocked hundreds of apps on their move to Forge. I appreciate that this has also resulted in the majority of features being core capabilities - regardless, we continue to work towards delivering key and niche use cases, such as extensions in Confluence attachments or publish conditions.

I highly recommend prioritising adoption of Forge where possible today - it’s possible to co-mingle your existing Connect modules with migrated Forge modules and remotes. This assists in building familiarity with Forge, while also providing us with more feedback on where we need to focus to help unblock you on your move.

1 Like
18

@AaronMorris1 I absolutely get your point. My comment was not meant to address the wider discussion around delayed feature development impact on partner roadmaps. Instead I wanted to give you some clarity specifically on the dynamic module development status and date

2 Likes
19

The carrot and stick game Atlassian plays is such a damaging strategy, essentially:

  1. Set unrealistic timeline to force migration/discovery/behaviour
  2. Don’t reassess that timeline until ~1 month before deadline
  3. Extend timeline and repeat the process

The problem with the approach is it enrages all stakeholders/partners, and destroys goodwill and trust in the community.

11 Likes
20

I would appreciate it if someone from Atlassian could address the financial aspect of this discussion and explain why the penalty from January 1, 2026, is necessary.

11 Likes