We can understand the benefits on your end for such a solution, it is definitely not ideal on ours as this changes our technology stack and creates a separation between cloud and DC.
We would like to make sure of one thing though ; As Atlassian will be taking on hosting the app, computing and storing it on its own infrastructure, will the cost of hosting be trickled down to the vendor?
Or in simpler terms: is Forge going to incur a cost to the vendor?
Regards.
I believe that this post is the most recent announcement related to this: Forge pricing update: free through 2023
The direct answer to your question is near the end:
What happens after December 2023?
In the spirit of Atlassian’s OCNB value , we still need more data on Forge app usage to determine a long-term economic model. Our preference is to keep Forge as free as we can: we see its primary value in improving Atlassian products to better serve every customer. In any case, we will always remain competitive against the platform costs and benefits of cloud providers. We will share an update on the long-term plan by September 2022 at the latest, though we endeavor to do so significantly earlier if possible.
That announcement sounds different now once we learned about the plan for Connect, and the idea of “no data&compute outside of Atlassian”.
In any case, we will always remain competitive against the platform costs and benefits of cloud providers.
Such competition will be illusory, if app developers will not be able to use other cloud providers.
Thanks @david2 - we are actively exploring our overall consent experience and looking at ways we can simply it for end users and Admins. Will update the community once we have something concrete to share.
Yes @jmort, with connect on Forge we want to soften the migration path and hence Stage 3 and Stage 4 are optional but recommended. We see this as a multi-year transformation, as we get more and more server customers migrated to Cloud, we need to support the ever growing needs that come up with enterprise customers related to trust, scale, security and compliance. This post aim was to share early and often on what we are thinking with the wider community and collectively work to shape the future journey of Connect on Forge.
You make a valid point on dogfooding, internally we have built Forge apps and we should be sharing that more. We are exploring ways to move apps built by Atlassian to migrate to Forge and will share back the learnings we get from those migrations.
What is the reason for sunsetting Connect?
We haven’t said we’ll be sunsetting connect besides deprecating support for JWT auth and remote iframes in due course, to raise the security bar.
Are you asking why we can’t continue to support remote compute or remote storage? We believe we will need to continue to support those in some form.
Are you asking why we can’t keep the connect modules that use those features around, but migrate them to a different kind of auth? We could do that, potentially, if Forge modules were found to be an inadequate substitute.
Are you asking why we’ll be requiring vendors to migrate to Connect-on-Forge, i.e. to go from a descriptor to a manifest, instead of adding a compatibility layer to forever handle the difference behind the scenes? Because there are various historical reasons why that’s more trouble than it’s worth, for example the fact that connect apps are identified by a user-supplied key, which isn’t guaranteed to be unique for non-marketplace apps, rather than by a UUID in a centralized system (as is the case with Forge).
Not sure if I understood the question correctly, let me know if not and I’ll have another go at answering 
So from a Connect developer’s perspective - what’s left after JWT auth and remote iframes are removed?
I’m not trying to be difficult - but isn’t marketplace.atlassian.com that register today? Aren’t app keys much more user friendly?
Today’s state of forge modules aren’t the same. What’s the path to take me from any connect module to Non-connect forge? If it’s missing - what’s the path and timelines?
You say Atlassian has built Forge Apps. Maybe I’m just blind, but can you point me in the direction of CDAC threads created by the people working on those Apps? I am assuming they’ve run into issues from time to time? Things like missing features, confusing/missing docs, outages, bugs, etc?
I can’t seem to find anywhere where Atlassian developers working on Forge apps are participating in that.
To me, this makes it look like there is no real dogdooding going on. Because your developers can simply backchannel, using resources that are not available to anyone else. Which in turn would also mean that their experience developing for Forge would be dramatically different than the experience we vendors have.
Of course, I could be horribly wrong about that, and would love for someone to correct me.
So from a Connect developer’s perspective - what’s left after JWT auth and remote iframes are removed?
I admit that makes up a lot of Connect, but there are some extensible things that don’t use those, like custom fields.
isn’t marketplace.atlassian.com that register today?
If the first step for making an app was always to create a private marketplace.atlassian.com listing then that would suffice to keep enforce app key uniqueness, but that’s not the case; some Connect and Forge apps never even make it on to marketplace. Also, marketplace does not serve as an authoritative register for other things we want to know, like where an app is installed.
Aren’t app keys much more user friendly?
I’d argue that an app key as a primary identifier is less user friendly than letting the system generate a unique identifier - to give just one example, if you put your company name in your app key and then your company changes name or hands, you’re stuck with the old name in the key. Additionally, with a UUID you can’t accidentally create collisions between different test instances of your apps by giving them the same key.
Today’s state of forge modules aren’t the same. What’s the path to take me from any connect module to Non-connect forge? If it’s missing - what’s the path and timelines?
We’re working through that that at the moment - that is a good question in particular when it comes to things like existing macros saved in Confluence pages, which we’ll want to ensure keep working if those macros get replaced with the Forge equivalent.
Hello @AditiVenkatesh I want to bring to your notice that Forge does not support organisation level user proxy, which blocked some of our developers to build an app for our requirement.
Refer the issue - I can't login to forge - #3 by GauravAgrawal
A question regarding “state 2”, which includes:
Connect remote iframes must be replaced with Forge Custom UI or UI kit
One of the issues preventing us from moving to Forge (there are many others issues, but let’s focus on this one), is that the sandboxed iframes for CustomUI are more restrictive than Connect, specifically: no allow-popups.
I understand that this was an intentional decision, and that the recommendation for Forge apps that need to open links in new windows/tabs (<a target="_blank">) is to use the router from @forge/bridge.
In our case, this is not easily done. Our Confluence dynamic macro takes user-supplied JSON/YAML (either fetched from an external URL, or embedded into the body of the macro), which may include some arbitrary markdown.
We use a third party library to process this markdown, and by default any links in the user-supplied content are rendered with the target="_blank" attribute.
So as the app developer we are neither in control of:
target="_blank", nortarget="_blank"We are currently investigating alternate solutions that involve finding all links on the page that have target="_blank" and augmenting them with an onclick handler that intercepts the click passes it to @forge/bridge’s router.open(url). (This may not be achievable in all cases, since some content is dynamically rendered; so some links may not be in the DOM until later).
Will there be any affordance at “state 2” for Connect apps that currently rely on the sandbox="allow-popup" attribute on remote iframes, or is this something we need to address before we can reach “state 2”?
Hi Dmitry,
This update specifically relates to Atlassian Connect for Jira / Confluence. Though we are aiming to bring Forge to Bitbucket Cloud and our other Cloud products, we haven’t publicly announced timelines for them yet.
Hi @scottohara , I can’t give a definitive answer but I wouldn’t count on any extra affordance or exception besides the documented workaround. I’m interested to hear how the investigation goes.
Hi @emil,
If i understand your question correctly, all users with an Atlassian Account should be able to access APIs with OAuth 2.0. If you are specifically talking about access to JSM APIs then this should be available soon and well before State 2.
Cheers,
Sam Purchase
I’m obviously biased, but I think Atlassian are making a misstep here.
You are asking every cloud app vendor to undertake a move from Connect to Forge, which in itself is a significant ask, but at the same time expecting vendors to also rearchitect around the many small (but impactful) differences between the two platforms, such as different security restrictions.
Atlassian should, in my view, be looking at ways to remove friction for Connect apps to migrate, even if temporarily (e.g. in the case of the iframe sandbox attributes, make them identical to Connect remote iframes for state 2). After apps have successfully migrated to Custom UI, then plan to transition to a stricter set later.
At the moment the jump from state 1 to state 2 feels very much like the “How to draw an owl” meme:
I completely agree with Scott here.
We all agree that the idea behind Forge is great, so we all would love to develop and migrate apps on this platform. However, We tried to port multiple times (in fact, we try every month) but there are so many small blockers that it’s not possible to port Connect apps to Forge without massively reducing features (there by upsetting our common users) or finding a very unsustainable workaround.
We are being forced to adapt to Forge even though there remain these small hurdles. Very important things that we need to adopt are often ignored or redirected to Forge issue tracker, which has more than > 200 open issues with poorly written requirements. Most importantly, this issue tracker has no any visible priority or SLAs set on issues, so we do not know when or if at all we can expect Atlassian to fix these issues. This means we cannot even plan the Forge adoption in advance.
So it feels like Forge is shoved down partner’s throat. The issues I raise here are already raised many times in this forum, but nobody from Atlassian seems to take steps and responsibility to tackle these issues. We are quite worried about the whole Forge timeline.
No-one is being forced to adopt Forge yet. We are trying to share our plans ahead of time to help you prepare where that’s possible (and give us feedback like this). We know there are still hurdles in the way. We’re working on improving the public issues as a first step; sorry the channels for tracking feature requests feel so unsatisfactory thus far.
The State 0 to State 1 jump is supposed to be really low friction. State 1 to state 2 is a bigger jump, but I guess one way to tackle it is one module at a time. I’m sure there are ways we could look at easing the transition, but I’m not sure if easing the sandbox attributes are the way to go - alongside static assets, they are the whole point of the migration. The other approach, which I think can already be done today in many cases, would be to add the attributes to your own iframe before migration.
Thanks for all the feedback; please keep it coming.
Over the past few weeks, there’s been quite a bit of discussion on this topic, as well as important feedback from Partners and developers. We want to summarize the answers to a few of the questions you asked here in this thread (as well as on the blog) for greater visibility, and outline how we plan to address concerns.
We heard some developers express concern that Connect will be removed from service in 2022. We want to be clear: this is not the case, and we apologize for the ambiguity. The end of 2022 is the date when we expect that all apps will be able to start the process of going from State 1 to State 2 (and many will be able to start the process sooner). It is not a deadline for making the updates necessary to move to State 2, nor is it the date when any Connect services will be switched off.
In the spirit of OCNB, we do want to be transparent that remote iframes and JWT auth will be deprecated in Connect at a future date. We don’t yet know when the official deprecation date will be for these Connect features, but we are committed to providing equivalent functionality in Forge and plenty of time to make updates before any Connect functionality is removed. We know replacing these features is likely to be a significant undertaking for Connect app publishers, and because of this, we decided to provide this information early, even though the pathway to reaching State 2 is still being built.
If you use JWT and remote iframes in your Connect app, we ask you to collaborate with us, keep providing your honest feedback, and share the details of your implementation. Our priority is helping Partners get to State 2 with as little disruption as possible, and to do this, we need to understand your current architecture. This will inform both what we build for you and when.
We’re holding an Office Hours session on Oct 20 with the Forge Product team, and we invite you to sign up to attend here. Bring your questions, talk to us about the complexity you anticipate and the essential functionality you need—we take all of this into consideration for roadmap planning and we’re here to support you in this process.