That’s a surprising statement. I haven’t heard of any partners who’d be able to move all their Connect apps to Forge today, without sacrificing features. If you have analyzed this using Habitat (if it’s still in use), I’m pretty sure it wouldn’t be able to detect all blockers from our point of view (at least it didn’t when it was shown to us some time ago). Tool-assisted feature parity mapping can only go so far, and as you can see from the comments in this thread, Forge still has a lot of catching up to do.
We also have blockers for the majority of our 13 Connect apps to move them to Forge today.
As much as I would like to be able to have confidence in this, I would like to point out that we started at “you have nearly 7 months [… to] complete any necessary development work” and “The updates were announced ahead of the usual 6 month window to give partners as much time as possible”.
This ended up being 30 days or fewer to port certain features (if we are lucky), and it feels like the six-month window never actually applied in the first place. All of this makes it hard to trust guidance from the business team about timelines, and particularly the idea that the higher take rate will only be necessary for a “short” period of time. (This leaves vendors with only one real option.)
I join the chorus in saying that being “able to move to Forge today” is not the case for us either, and anecdotally, what I hear from other vendors falls largely in the same category. I too fear that Atlassian could be relying on bad or incomplete data to make the assessment that the majority of vendors can move to Forge.
Trying to be constructive:
Could Atlassian publish a list of apps that (according to their metrics) can already be moved to Forge? Let’s say, for example, the top 100 Connect apps by revenue. If a vendor’s app inadvertently ends up on the list, I am sure that we would be collectively happy to list off the tickets of the blockers that are preventing us from moving to Forge.
In the best case, Atlassian is right, the majority can move to Forge, and this exercise builds community trust.
In the worst case, there is still a lot of work left to do, and this provides Atlassian the additional detail it needs to understand which blockers are on the critical path for each app, straight from the horses’ mouths. (If Atlassian believes that everyone can migrate, but that is not actually true, I hope that they would like to know!)
Also, considering the commercial hit on apps that cannot yet migrate to forge, I suggest a bunch of free admissions to Team Europe for affected partners would be a nice gesture.
Allow me to add that Remotes do not work for us because of various UI modules like Forge Macros which Atlassian may consider to be mature replacements of their Connect counterparts are not in fact full replacements. For example, see:
Oh, sure. We are having to choose between dropping features (one example for us is publishConditions), or accepting the Connect on Forge financial penalty. We are also having to rewrite large swathes and seek workarounds because many of the Forge UI equivalents are not up to scratch.
But we’ll be using Forge Remote for our backend. This avoids the chargeable Forge modules. So at least for now, we are keeping our AWS infrastructure. It also allows us to do basic things that Forge doesn’t do right now, such as sending emails. Perhaps when Forge matures we’ll move more into it.
