Atlassian has been using a combination of various carrots and sticks to persuade vendors to move to Forge. I will summarize my comments here as “too much stick, not enough carrot”.
The way that Atlassian is approaching this transition, from a vendor point of view, is fundamentally wrong. What is particularly missing is Atlassian’s prior due diligence to draw a map of exactly how vendors can transition from Connect to Forge, for all of the capabilities that Connect provides, to show that there is or will be parity. Atlassian is now asking vendors to describe all the gaps, but I argue that this should start as Atlassian’s responsibility. You do the work first, then vendors will happily look at your comprehensive document and tell you if you have forgotten some nuance.
Connect has a significant surface area. Where is your upfront public document with a map that describes the transition path to Forge, for every single Connect module, for every web-item, for every context parameter, for each Connect JS API, for each webhook, for data residency, for migration, for anonymous users, installations, upgrades, permissions, admin approvals, lifecycle, and absolutely everything else? For Connect features that are not currently possible to implement on Forge, we need a link to the implementation tickets (if any) and expected delivery dates. And if you are going to remove a Connect feature completely, we also need to know that upfront. You are the ones making the decision to remove Connect, so why are you asking vendors to do this work for you?
Do the work, publish the document, then create a mechanism for vendors to submit changes to add to what is there, to fill in on nuance or add use cases you may have inadvertently missed. This needs to get fed into the same document. Saying that you do not need a document because you have a heap of existing FRGE tickets is not helpful, because a pile of tickets does not provide a comprehensive 30,000-foot view of the platform, and it is not organized in a hierarchy or in a way that any outsider can understand. This should be in one single, living document that allows all stakeholders to easily assess the state of the platform. (Or make it a hierarchy of Confluence pages or whatever it is that makes sense, but the point is that it needs to be comprehensive and in one top-down place.)
As a Marketplace vendor, we need to see this to determine if we can move our product to Forge. If the platform is not ready, vendors should not be forced to waste time on a partial migration only to have to stop halfway through after finding out that a critical feature is still missing.
And if you do not have such a document, how can you conceivably say in good faith that you are going to force vendors to transition from Connect to Forge, when you yourselves do not even know the state of parity of the Forge platform? If Forge is truly a better platform and customers are asking for it, vendors will migrate organically. I do not believe the claims that Forge has “dramatically increased developer velocity” have played out in real life.
We have gone down this path recently with the Confluence Cloud V.2 API transition. It was the same story: a forced transition, no public mapping of APIs, relying on vendors to create CDAC posts (and later, to create ECOHELP tickets) to describe the large swath of things that the Atlassian team forgot to implement, and transition deadlines that have been pushed off too many times to count. (And it is still not even at parity.) If a thorough mapping had been done upfront and a mapping document published, it seems like the majority of these problems would have been alleviated. Can we please try to do better here?
Let me add that asking vendors to fill in a private survey, rather than describing issues publicly, collectively wastes a huge amount of time. If vendor A has already described a problem that I also have, I should be able to “+1” it rather than spending 30 minutes writing the same thing again. The other vendor may also have a problem that I did not even realize that I had, until I see what they have written, so public knowledge is even more helpful.
Can you think if there might be a better way to coordinate this feedback? Ideally, as I mentioned above, Atlassian would go create that mapping document and come back in a month or two to solicit real comments on what is missing.
I also do wonder exactly how interested Atlassian is in gathering this feedback in the first place, given that the CTA for the survey is buried in a two-word text-only link, literally at the very bottom of a 10-page blog post. Perhaps this was inadvertent, but you can surely do better.