Clarify the future of Atlassian Connect

#1

Hi,

Is it possible for Atlassian to clarify the future of Atlassian Connect? Notably, the future security/data requirements for Connect apps once Forge is published?

  • Atlassian introduced Forge during the last Developer Days,
  • To the question “Should I use Forge to build my app”, they said “Existing apps: Use either Connect or Forge. New apps: Use Forge.” — It seems an opinionated push, as if Atlassian had information about a forecoming Connect deprecation.
  • To the question: “Is Atlassian Connect deprecated?” they answered: “Atlassian Connect is here to stay”, which is generally the codeword for everything deprecated, adding “but we expect that ease-of-use and features of Forge will make that developers will migrate” (paraphrased with my own words).
  • Our app needs to lookup the data in a database, so we’ll have to keep an external storage (either with Connect or with outgress permissions in Forge). But it seems Atlassian wants to emphasize the data ownership capabilities of Forge to customers (which are excellent: data is backed-up by Atlassian, in the future it could be kept in the customer’s location for example, egress in Forge is controlled by the administrators…). What security checklists and data residency features will Atlassian require from Connect apps, to be able to stay relevant on the Marketplace? Will Atlassian develop, for example, a “target_country” header in the Connect installation payload?
  • We have to develop on Connect right now because customers are forced to move to the cloud now, but in 3 months we’ll have competition from the pure-Forge apps. Are we going to throw away the code of our current UI in 6 months, because we are pushed to migrate to Forge?
  • Also, since Forge and UI Kit are domain-specific DSLs, programmers can’t reuse their skills in other companies, so my current programmers will start leaving if we are on pure-Forge.

My questions:

  • Will data security requirements on Atlassian Connect apps quickly increase, which will make it practically impossible for 2-3 developers to maintain a Connect app by next year? Is it just a bad idea to introduce a new Atlassian Connect app in 2 weeks?
  • What will be the new requirements for Atlassian Connect apps by next year?
  • Is an app that requires a database a bad business idea for the Atlassian platform in the long term?

Thank you,
Adrien Ragot, for Requirement Yogi

11 Likes
#2

Hey Adrien,

As the PM in charge of UI features on Forge, I can’t answer all of your questions but just wanted to touch on your points about UI:

We have to develop on Connect right now because customers are forced to move to the cloud now, but in 3 months we’ll have competition from the pure-Forge apps. Are we going to throw away the code of our current UI in 6 months, because we are pushed to migrate to Forge?

We just launched custom UI, which lets you use arbitrary HTML/CSS/JS on Forge. As long as your frontend is static, you should be able to move it over with almost zero code rewriting (if not now, very soon, since we’re rushing to bridge the gaps between Connect and Forge). If you were pushed to migrate to Forge—which would only happen if there wasn’t going to be any functionality loss and significant security advantages—you wouldn’t have to throw away your current code.

Also, since Forge and UI Kit are domain-specific DSLs, programmers can’t reuse their skills in other companies, so my current programmers will start leaving if we are on pure-Forge.

I see the point you’re making.

  1. You don’t have to use UI kit to be on Forge, custom UI should allow developers with almost any web skillset to work at your company (unless they know PHP :stuck_out_tongue:).
  2. UI kit has a very similar API to React Hooks. I’m not fully convinced you’d be locking people into something with little applicability elsewhere—but I get your point. We’ve been looking at ways to make UI kit less domain-specific but don’t have anything to share right now.
#3

Hi @aragot,

Thank you for sharing your analysis and perspectives.

First, let me try to share some context: we want to ensure customers can make informed choices. So beyond the minimum security requirements, a developer can choose to participate in Atlassian’s security programs, or not, and that will be reflected in Marketplace listings that communicate this to customers. I have not heard of the basic requirements preventing a small team maintaining a Connect app and wouldn’t expect that to change. Either way, this is the whole reasoning behind Forge: to make it easier for all of you to build secure, robust apps that can serve more customers.

As you’ve highlighted though, there are real use cases that require infrastructure outside of Forge though. That is part of Forge’s intended design: an easier start, higher up the stack, but the flexibility to break out when you need to. And in those instances, we aim to provide transparency to customers. Essentially, rather than having to have the entire app function outside (or “remote” to) the customer’s Atlassian Cloud, it’s only the pieces that need to, which should result in a net decrease in attack surfaces and maintenance.

So, specifically on your questions:

  • It’s not a bad idea to introduce a new Connect app in the order of weeks, though of course we recommend building on Forge if you can. If Marketplace integration is the only thing stopping you, consider that the EAP is only a few months away. If you need more functionality than being able to sell on Marketplace (or remote databases, see bottom bullet below), we are always keen to hear what.
  • We are not planning any new requirements for new Connect apps. If we did so in future, we would give as much notice as possible.
  • If your app requires a remote database (outside of Forge) to fulfil the user need, that is not in itself a bad thing; in fact, we expect some apps will continue to need such remote infrastructure. We don’t want to rebuild it all :wink: and that is part of our strategy to provide better granularity and visibility to customers to make informed choices. Something worth noting: if your app requires this functionality, so does any competitor.

I hope this helps you, and please feel free to follow up.

Thanks,

Joël

1 Like
#4

Hi both @huw and @JoelKalmanowicz,

Thank you for your kind answers.

I am not sure Atlassian project managers have identified that there was a 6-months gap between announcing the deprecation of Server (so customers rush to the Cloud) and publishing Forge 6 months later. It means in the meantime, we have to develop temporary Connect apps.

Each time, we have to divert developers from serving customers to supporting:

  • Data Center
  • Various badges, security review, etc.
  • Bug bounties
  • Server deprecation / Connect
  • Migration assistant
  • Now Forge
  • Apply to Atlassian Ventures
  • And the Covid lockdown has a hit on our productivity.

We’re extenuated. We haven’t had time to program actual new big features for customers for the last year, and it is hard to recruit given Atlassian closed the Server revenue, and given the techs for Forge are non-sexy.

We’re bored of doing migration tasks and tired of the lockdowns. It would be nice, although as I understand the opposite is going to happen, if Atlassian could give vendors a bit of time to stabilize on Connect and have a very progressive migration path to Forge.

I’m afraid your marketing is instead going to push large, GDPR-sensitive customers to enforce a Forge-only policy as early as April, thereby threatening all vendors who didn’t grow quick enough to have enough developers to move to Forge in April.

Best regards,
Adrien Ragot

PS: Case in point, I had recruited to be 5 developers in total, but we had to cut back from 5 to 3 developers after Atlassian killed off the Server revenue stream, and we’re not sure of keeping the 3 people if our Cloud products don’t replace the Server revenue.

7 Likes