Remember that app migration survey? Here’s what we found…

[CaitlinMcCurrie]

Recently I reached out to you all and asked you to fill out a survey about what you might require to build your server app on the cloud and on Forge.

Thank you so much for taking the time to respond. We collected data on 356 apps, which is fantastic and is helping us better understand the blockers you are experiencing in the shift to the cloud. As promised, I’ve read each response carefully and surfaced this information to the teams to help understand your blockers in the transition to cloud. We are currently exploring the implications of this information.

Although not an exhaustive list, some of the most frequent challenges we heard expressed in this survey:

Platform quotas
We heard that limits such as the 10s Forge runtime timeout and storage size are blockers for Forge adoption, especially those developing more complex apps.

Storage complexity
More sophisticated data storage capabilities is an essential requirement for Forge, particularly relational capabilities. We heard that at least 31% of apps that store data require relational capabilities.

Product Capabilities

Many of you shared that the lack of extensibility parity between Connect and Forge was a blocker for Forge development. Confluence & Jira capabilities were also the clear blocker for most partners attempting to close the gap in features between on-premise and cloud apps.

Parity of UI extensibility
UI extensibility does not yet support the requirements of more complex apps.

Tech stack limitations
Lack of Forge’s support for various tech stacks, particularly language can be a blocker for some of you.

Migration
We’ve heard your concern about the future of Atlassian’s focus on the cloud:

• What this means for migrating your app to the cloud
• And for the migration of customers’ data.

Resource constraints
Especially for smaller teams, we heard that it could be challenging to keep up with the number of asks we make of you. Forge and the move to the cloud are yet another ask, and we understand that you need to make trade-offs when deciding priorities.

Value of Forge to you and your organisation
Many of you shared that you weren’t sure of the value that Forge would bring to your organisation and app(s), especially how building your app on Forge compares to the value of spending your time on other efforts. We understand that Forge may not be ready for every partner now, but it will be in the future.

Extension points for Bitbucket and JSM
We heard that many of you intend to develop a Forge app for either Bitbucket & JSM but are limited by what you can build and whether you can monetise your apps developed for these products.

Once again, we appreciate your taking the time to share this feedback. The teams are currently discussing how we address these challenges.

What do you think of this list? Let us know if there are any significant omissions. If you missed the survey, let me know your thoughts in the comments below. Or feel free to share your thoughts on your app(s) in the survey link, I will keep this open and review any new data. We will be asking you for more technical information on your apps in the near future and this information will help us build in the right direction.

Something that we were surprised by was the absence of a few requests that we heard were important in our conversations with many of you:

• Observability
• End-user consent
• Team ownership of an app

So tell me, how do those requirements weigh up against that list? Are they blockers we should be prioritising as well? I’d love to hear what you think.

Your friendly neighbourhood researcher,

Caitlin

[UlrichKuhnhardtIzym1]

Thanks for sharing, @CaitlinMcCurrie ! Hurray for Bitbucket + JSM with Forge! Perhaps even

• PvA integration for Bitbucket+Forge apps?!

Your friendly neighbourhood MP vendor

[jbevan]

I think the reason that “observability” and “team ownership” did not come up is that the other concerns are earlier considerations. If Forge was more ready, then those two concerns would be higher up the list…

[CaitlinMcCurrie]

Thanks Jon. This was my suspicion, but good to hear it from the community

[jmort]

Thanks for sharing the findings, it is much appreciated. We often don’t hear what you learn after filling one of those out.

I think @jbevan has it spot on. The things on the list are fundamentals. There is no point in building as a team if the host applications don’t support the capabilities you need. Equally you can’t build a complex enough UI in Forge UI to require a team to collaborate on it. We haven’t got close to needing the observability tools because the number of production Forge apps is small, and most have been written deliberately small (taking a small risk) to take into account all of the unknowns (like what it is actually like to run one in production).

The resource constraints finding is something that all vendors have been shouting about for years. Atlassian actively hampers our efforts to deliver value to customers by constantly changing things and pushing new requirements on us. Forge should be something that vendors want to jump on and are thankful for, but the reality is it is yet another change we have to deal with.

[david2]

I agree 100% with both Jon(s). Observability and team development support are so basic and obvious concerns that everybody is taking them for granted - and nobody realizes that forge is so far behind on this since other, more functional concerns, are preventing vendors from even starting development.
David

[jbevan]

@jmort

Forge should be something that vendors want to jump on and are thankful for, but the reality is it is yet another change we have to deal with.

I think the scenario for vendors is worse than this. We’re getting signals from Atlassian that Connect is not being invested in, and will change in significant ways and/or be deprecated in the future. So we don’t have a choice but to investigate/pursue Forge, only to find out that its woefully lacking (understandably at this point in its lifecycle) and all the things we want in Connect we’re not going to get while Atlassian rebuild everything on Forge.

[dmitry.astapkovich]

Another blocker that wasn’t in the survey is app licensing. At the moment vendors have to add their own layers to handle customer licensing because there are way too many gaps. But at least with Connect apps we see the requests from the customers on our side, so we can block the access if the license is not presented or paid in time.

With Forge we don’t have the access to that level. So basically it means we simply won’t get as much money as we can with Connect.

[aragot]

I have a HR problem with Forge, and a solution: It’s hard to appear sexy as an employer if we’re only using a proprietary JS framework. Doing React/SpringBoot/Hibernate was the sexiest thing at the moment (besides pure NodeJS), and our plugin’s core Java module was pretty awesome in our business (Requirement Yogi), after spending years polishing it.

Possible solution: If we could just upload this core Java library in Forge and wire all the JS with it, we’d be able to retain the talent and hire new one. We’d also be able to deploy it for Google Docs and Microsoft Teams using the same core java.

Otherwise, I’ll have hard time recruiting engineers and telling them we’re only going to do Excel macros, err, Forge macros.