@asridhara please don’t take this personally, but I think the Head of Product, Forge is not the person that should be responding to this thread.
Back in the 80’s there was a Dutch TV commercial for a cleaning product, in which the head of the cleaning product said that they highly recommended everyone using said cleaning product. I fully expect the Head of Product, Forge to highly recommend everyone to start using Forge.
Is there a way for us to escalate this?
I’m fully aware that Atlassian has already made up their mind, because they always have by the time something is posted on CDAC, but there are several very important comments in this thread that are not being addressed and given the current responses warrant escalation.
To re-iterate:
the current private feedback loop is, given the fragile state of trust in the ecosystem, very much a red flag. As mentioned by @scott.dudley, it is A) a waste of time for us to fill in the same responses as others, B) it does not allow us to vote for things we hadn’t thought about or tried yet and, added by meself, C) it is absolutely unclear to us what Atlassian will be doing with this. The lack of public record is disturbing.
you may have all these internal tooling to track the parity gap, but there isn’t a real overview such as @scott.dudley alluded to. There is the Jira PD board, but that doesn’t contain everything and there is the list of resources but that only redirects to scattered documentation. There is no single source of truth.
For some reason, we are failing to communicate with you that we need to do this together. You are loosing us, and it will cost Atlassian, Partners and, more importantly, our mutual customers.
Please, if you can only fullfill the role of the Head of Product, Forge, which is totally understandable, make sure to forward this thread up the ladder to someone that can actually engage with the partner community and can make decisions that show us that Atlassian has heard us and is going to do what is best for this ecosystem, incl. our mutual customers.
I appreciate the links you posted, and I do believe that the Forge team is well-intentioned in trying to close the parity gaps. However, the existing documentation misses the mark. By a lot. I believe the community would appreciate Atlassian itself investing a lot more effort here, before demanding such effort back from the community.
Can you find a way to regularly publish this Habitat data of “detailed view of Forge parity compared to Connect” so that vendors can see it?
I was suggesting that you “make a document” not just only because vendors would like to have a document (we do!), but also because (in the process of making the document) I would hope that it will force Atlassian to methodically go through every single feature of Connect and determine its mapping state, if this has not already been done.
As an example of “missing the mark”, let’s even constrain the discussion to the first item on my list: web-items. Looking at this in the context of Confluence:
In one of the Connect equivalent pages that was indirectly linked above, I count Forge mappings for six (6) web-item or web-panel locations for Confluence.
I downloaded the descriptor of the official Atlassian Confluence Connect web location finder app and searched for “location”. It shows 47 (!) such locations in Connect:
Giving Atlassian the benefit of the doubt, I will assume that perhaps some of these locations are deprecated or no longer supported, but there still seems to be a huge gap.
I found another random page via Google with a pseudo-mapping that confirms roughly another dozen web-item points that do not yet have any mapping from Connect to Forge. Is this list complete? Maybe, who knows?
In the roadmap you linked, yes, there is a ticket to “increase web item surfaces”. The timeline says that it should have already been completed in Dec 2024 (?), and in the ticket detail, it references only a single web-item for the Jira project navigator. This is not very helpful either.
Try to imagine yourself in the shoes of a vendor. The information you need to analyze the very first example (“are my Connect web-items compatible?”) is already spread across at least three different places. Nothing is accessible top-down. None of the locations are comprehensive. And looking at what does exist, it seems that there are still coverage gaps (what about the other two dozen locations?). For the items that are actually listed but which do not yet have an equivalent, there are no due dates, or even indications of whether or not they are planned to be implemented or if they will be removed.
I see three possibilities:
Atlassian is sitting on this data internally and not sharing it.
All of this data is actually shared somewhere (where?), but it is not organized in a way that allows vendors to find it easily.
Atlassian is truly unaware of these gaps and is asking the vendors to fill in the details.
None of these are great. Where I take particular umbrage is how Atlassian is asking vendors to spend time filling in surveys without providing this information first. Sure, if there is a subtle issue related to how I am using a given Connect module (and whose migration plan has already been well documented by Atlassian), yes, I will be more than happy to fill in the nuance.
More directly, I should not need to tell Atlassian that there are potentially 30 web-item locations that may or may not be mapped. But apparently, I do? Or not? Maybe? Who really knows, since there is no authoritative source? And since the surveys are being conducted in private, this also means that every other vendor has to go through this too, with a significant presumed duplication of effort.
It is exactly for this reason that I am not particularly interested in filling out your survey. (Remember, I only got around to looking at the very first item on my list from earlier.) This is also why I say that the first big push of effort needs to come from Atlassian.
Out of 1477 forge apps listed on the Atlassian Marketplace, there are 41 that have 1000+ installs (7 of which are from Atlassian).
Out of these 41 apps, there are 11 that have no data egress (3 of which are from Atlassian)
That means that to date (since 2019(!)) only 2.7% of the apps have 1000+ installs and only 26% of those apps have no data egress. Not to mention that more than a quarter of those no egress apps are from Atlassian.
How is this justifiable from a business perspective?
Allow me to rephrase this. Of course Atlassian considers this a wise business decision, otherwise it wouldn’t have made it.
What the above number show is that the “carrot” has not worked. Marketplace Partners are not migrating to Forge on their own volition. It is clear that they do not see the benefit. For them, this is not a justifiable business decision.
So Atlassian is now handling the stick. And it will work. Atlassian will see partners migrate to Forge, adoption rates will rise and Atlassian will be able to congratulate herself on successful migration. But it’s all fake. Atlassian forced partners and of course partners will follow.
But it comes at a high cost in terms of trust, and value delivered to customers.
So my question is: who within Atlassian is ultimately responsible for deciding to use the stick? And can we, as partners, have an honest conversation with that person in order to tell them directly what they are about to loose because of this decision? Is there a middle ground that we can find between Atlassian meeting her targets and Marketplace partners feeling more confident in migrating on their own accord?
I’m not sure who can answer this question, so I’m CC-ing @ChrisHemphill1 and @dmorrow who can hopefully make sure this thread is seen by the right people.
Could you please prioritize revealing pricing for Forge?
It’s incredibly challenging to plan a migration without knowing the running costs. What if 50% of apps no longer remain profitable? What if half of the Marketplace businesses are forced to exit Atlassian altogether?
We’ve been running our business on Atlassian for almost 9 years, and this uncertainty is causing significant stress.
Additionally, there’s a broader concern regarding the message sent to customers about the “Runs on Atlassian” marketing strategy. Communicating that “your data is not safe with Connect apps” and indirectly implying that “connect apps may leak/loose/reveal/steal your data” creates unnecessary distrust. Is this messaging designed to push customers toward Data Center?
We value transparency and collaboration and hope to see a more constructive approach moving forward.
Remie’s questions are very legitimate. At Requirement Yogi, we are faced with the extremely-heavy investment of migrating to Forge, after working at a loss for years on Connect.
Connect has been a heavy loss, and so will be Forge, and this is not visible to Atlassian because DC sponsors the costs. If we charged Cloud customers the real cost of developing on the Atlassian platform, they’d be in for a nasty surprise, like 3x or 6x the price of the same apps on DC. Don’t you own Atlassian stock? Do you really want to make it a loss for both partners and customers? Should it be a bad business decision to choose Atlassian products?
So, is there any way that Atlassian can invest a little more in making the work of vendors easier?
Have real “devrel” (developer relation) teams, that are actually able to perform Remie’s and Scott’s suggestions,
Have APIs developed on-demand for vendors who need them, rather than the usual corporate speak of “Gathering interest”, “We’ll integrate it in a more global program” and so on (We’ve been struggling with a 1/10th of the necessary APIs for 5 years… and yet, they’re always being refactored),
Use normal tech like React and Maven, rather than a proprietary platform like “Forge UI” with mandatory non-reusable expertise for developers, so that we can actually hire good developers? Do you really want partners to be the Visual Basic-type of people? (Yes I know, “But you can use Forge Remote”, i.e. corporate workarounds that don’t answer the needs).
In any case, Remie Bolte articulates the problems very well.
I want our teams to be able to spend more time building valuable things for customers, and less time reacting to Atlassian’s changes.
We’ve just wrangled the Jira 10 / Platform 7 update, and Jira 11 has already been announced for 2025. (I’m glad our teams didn’t also have to deal with the same upgrade on Confluence!)
We integrated with JCMA to enable migrations to Cloud, which did not end at the end of Jira Server. Customer migrations to Cloud seem to be more motivated by sticks than carrots.
We need to adjust our app interfaces to work with changes to Jira Cloud UI and navigation.
The term “issue” is due to be replaced at some point in early 2025, which hopefully will only be a terminology change, because we have no answers yet about any technical changes for this.
This is alongside regular API changes and deprecations, which would on their own be reasonable.
This feels like yet another change getting in the ecosystem’s way. How will this help us provide value to our mutual customers?
I can see Atlassian pressing onwards with the fresh new technology, but I have not seen indications that it is worth it. I understand wanting it to be a worthwhile investment, for Forge to have been a success – but is there any condition where Atlassian would respond to a changing situation over following a plan?
What seems to be the primary issue with Connect and now Forge, is that, unlike P2, Atlassians are not using it for any complex core functionality and there seems to be no incentive to change it.
And without incentives, what is the point of building on top of the inferior platform when you have direct access to all private APIs.
For example, why JSW and service desk, historically P2 plugins, weren’t considered to be implemented on Connect after separation of cloud/server codebase? Why Jira Plans weren’t built with Forge?
You know what, I have a good proposition for you @asridhara and @SeanBourke: how about Atlassian migrates all her own Connect apps to Forge first, and then we can have a chat about sunsetting Connect, ok?
Oh and no cheating like Atlassian did with Automation or ProForma, turning it into native features. No I mean real migrations.
We understand that partners need visibility of Forge pricing to make an informed decision about how they plan to build their app and how they may want to adopt Forge (i.e. remotes vs hosted components).
We’ve already marked this as a pre-requisite to the start of the first phase (No New Connect Apps on Marketplace) and would not begin the deprecation period without this being publicly available beforehand.
Runs on Atlassian fulfils a customer request we’ve heard for many years. We know customers look at many trust signals when evaluating apps, and programs like Cloud fortified will continue to be important, particularly for remote apps. The goal of Runs on Atlassian is to transparently provide the information about egress and hosting platform that our mutual customers are asking for.
Runs on Atlassian does not replace remote apps and there are very real use cases which can only be achieved with remotes. Our intention is provide the flexibility to decide whether you want to leverage Forge storage or compute, or want to utilise Forge Remotes to host these services yourself.
Atlassian Connect and Forge both power key capabilities which are managed by dozens of teams. These default apps cover many common and critical surface areas, which our customers rely upon daily. Many of these rely upon the same APIs and extensions which are available to apps today.
Here’s another example of a feature “in waiting” for Forge: FRGE-208 .
There is no information if this feature will be delivered on Forge or not. If not, that will break quite some connect apps.
If Atlassian ever used any of their own tools they require vendors to use there would be no issues. That’s always been the issue. It’s why P2 worked so well. Atlassian used their own platform. It’s a perfect suggestion. Most likely they won’t convert a single app themselves if history serves.
Oh! Great @SeanBourke ! Please give specific examples if this is true of any Atlassian features?! Not exactly sure what you mean by ‘default apps’ either?
Either way if this is true please provide specifics, but historically speaking this has definitely not been the case.
Crucial Feature missing from my perception so we could even consider a migration:
User Impersonation (especially in web triggers), tracked in FRGE-1214 - FRGE-493
In addition:
It’s a shame that the unique capability of Forge to build cross-platform apps natively is killed by the Marketplace.
Allowing Apps to build their own Rest API’s seems not really possible, only via web triggers which is quite ugly
Generally speaking our Forge Apps have been quite stable and successful, the Developer console logs got a lot better and are actually useful. However Connect still feels a lot more like the Full Version to build Atlassian Apps.
We need a document with a feature comparison / migration path!
Additionally, it would really be great if Atlassian could provide an opt-in API gateway for apps, which would handle all authentication on Atlassian side and pass the signed request to the app backend.
@SeanBourke@asridhara could you please provide some details on how the phase out of Connect will impact Bitbucket? The linked blog post does not mention Bitbucket and thus it’s not clear how it will be impacted.
Right now it’s not possible to publish a Forge app for Bitbucket to the Marketplace - if Bitbucket was included in the phase out Connect I would expect this limitation to be implemented prior to Phase 1 which mandates that “all new apps published on Atlassian’s Marketplace must be created on Forge.”
Hey @joshp - PM for Bitbucket Cloud here, thanks for your questions.
Bitbucket Cloud’s implementation of Connect has historically been a bit separated from that of Confluence and Jira, so the phase out of Connect is being managed independently.
However, we 100% are in the process of also EOL’ing Connect on Bitbucket Cloud, and will have detailed information about that being released very soon (1-2 weeks).
We’re 100% cognisant of the need to have capability parity between our Forge vs Connect implementations before any EOL, and that’s something we will be making sure occurs.
Key thing to note is that today, Connect apps for Bitbucket Cloud can only be listed on the Marketplace as “non-paid”.
We expect that in the short-term, Bitbucket Cloud Forge apps will be the same. However, we do plan to bring “Paid Via Atlassian” to Forge Apps for Bitbucket in the near future as part of our wider campaign to standardise Bitbucket extensibility onto Forge.
Stay tuned over the next 1-2 weeks, we will have an official announcement including information on Bitbucket Forge apps in Marketplace.
If only I would get a penny every time an Atlassian PM said this. I would suggest Atlassian to stop making any comments about Paid-via-Atlassian for Bitbucket cloud as it can only disappoint.
To paraphrase Chuckie Sulllivan in Good Will Hunting:
Let me tell you what I do know; every day, I open my browser and check my apps. And we go to work, we create a few bugs, have a few laughs, and it’s great. You know what the best part of my day is? It’s for about ten seconds when I browse to MPAC to when I get to see the apps. ‘Cause I think maybe the page will open and I’ll click on our Bitbucket app and it will have Paid-via-Atlassian. No announcement, no “in the near future”, no nothin’. It’s just there. I don’t know much, but I know that.
