Join us for a Developer AMA with Tim Pettersen

What’s the most imaginative/awesome app that you’ve seen an app vendor build which made you go “I wish I had built that”? (Yes - I know that’s probably like me asking you to pick your favorite kid :wink: ).


There seem to be more frequent outages with large impact on the developer community ( and Forge CLI version 5.0.0 - 31 August 2022 for example). Are you seeing the same and what can we as a community do to help?


When is the next app week and where? Will there be more physical developer events? Can the community suggest locations?


Many/Most Forge example apps have thankfully been onboarded to Renovate over recent weeks - can we expect these examples to be properly maintained (and ideally evolved) going forward so that new Forge developers won’t face unnecessary onboarding hurdles (that hasn’t always been the case in the past)?


The Forge CLI templates have recently been moved from an OSS repository to an internal service - can you expand on the reasoning behind this, or maybe more generally, why Atlassian seems to have such a hard time embracing OSS collaboration, in particular within the ecosystem (many other platforms maintain their entire DX tooling as OSS and benefit greatly from community contributions)?


A significant enabler/accelerator for onboarding developers to a new project/platform is a fully functional CI/CD environment. IIRC a native CI/CD capability had been part of the initial vision for Forge, but didn’t make the cut, and hasn’t been mentioned (much) since.

In an ironic twist, the simplistic Forge and Bitbucket Pipelines example is in itself broken since May 2021, and most other Forge example apps don’t even use Bitbucket Pipelines in the first place.

Will Atlassian provide a better DX around CI/CD capabilities for Forge apps going forward?

  • By chance I just stumbled over Damien Lauberton’s recent and comprehensive blog post How to Configure CI/CD for an Atlassian Forge App while jotting down this question, and it has neither been announced in the community nor referenced from the Forge docs yet, maybe you could derive (and maintain) a tutorial from it?

What is the ratio of Cloud customers who has customised 1 or more Forge apps for their internal use? A possible definition of internal use app can possibly be

  • not listed on Atlassian Marketplace
  • more than 30 invocations a month

What are the plans to let more Cloud customers be aware that they can use Forge apps to improve their Cloud sites?

Maybe there could be a Forge Developer Directory or a specialisation where Cloud customers can search for partners who can help them to customise a Forge app (or even P2 app).


Is it possible to provide more info on the sites that have installed free apps on Marketplace?

  • Company Name
  • User Tier
  • Cloud ID/Client Key
  • Monthly/Annual plan

Currently, it is not possible for app vendors to know who has installed their apps unless it is a paid app.
Without the technical contact info, it is not possible to reach out to the users during the following scenarios

  • errors due to misuse or bad data
  • security advisories
  • breaking changes

Having said that, will it be possible to provide a platform for marketplace partners to reach out to the technical/billing contact? That will reduce the effort on the partners on gdpr and privacy issues. In this case, the marketplace partner can choose by company name/site without knowing the email addresses.

It will also help the customers to opt out of marketing emails easily while remain subscribed to important emails.


One reason for Jira’s popularity is the availabilty of plugin extensions to support integrations and add features which is not available out of the box.

Given that most SaaS platforms only allows simple integration to 3rd party web services, Atlassian has distinguished itself with Connect & Forge which allows a much deeper level of integration with Atlassian Cloud.

What do you think are the key challenges in providing a developer plaform (Forge) for Cloud apps vs Server/DC apps (P2)?


My #1 priority in the short-term is advocating for improved change management and incident management processes for partner impacting changes across Atlassian. While there are all sorts of exciting opportunities to enhance Atlassian’s ecosystem developer experience, it’s critical that we have a stable and reliable platform that evolves in a manner that is predictable and empathetic to our partner’s technical and business requirements. While we’ve made some good strides in this area over the last 6-12 months (such as revamping our incident security levels to better reflect impact to apps and partners, and streamlining our ability to accept and escalate incident reports from partners) we’re also exploring some broader improvements to partner communications during incidents, deprecation policies and processes, and other strategies to reduce the number of disruptive changes and incidents that impact ecosystem developers.

In the medium term, the Developer Experience team and I are working to increase partner empathy across Atlassian. Atlassian is a very large organisation now, and growing quickly. While most Atlassians have an awareness of the Atlassian Marketplace and the importance of partners, many lack a deep understanding of the nuanced dynamics of our Ecosystem. This means that R&D teams sometimes overlook opportunities that could provide mutual benefits for partners and our customers, like new extension points or investing in use-cases that could be solved by app developers. The breadth and depth of our varied Ecosystem-facing platforms and APIs also mean that well-intentioned projects delivered by any given team at Atlassian can occasionally have unanticipated negative impacts on partners. Increasing empathy across ~11,000 people is no small task, but we’re making some in-roads today by partnering with R&D on critical projects to ensure ecosystem perspectives are represented, building out playbooks and guidance for other teams to help them better understand and engage with ecosystem developers, and running internal training and evangelism initiatives—including some “get ‘em while their young” tactics like injecting Ecosystem awareness into onboarding materials for new Atlassians.

In the longer term, my “north star” objective is to ultimately help transform Atlassian from being a product company into a platform company. If you saw our COO Anu Bharadwaj’s keynote at Dev Day ‘22, you may have heard the term “Atlassian Economy” which refers to a bold new strategy to leverage our platform and scale our ecosystem. This strategy was one of the things that motivated me to switch from Engineering to Developer Experience—you and the rest of our ecosystem developers are right at the heart of the Economy vision, and I’m keen to use the momentum and excitement around Economy to rasie Ecosystem awareness across Atlassian and ensure Ecosystem developer interests are baked firmly into our R&D processes and the DNA of every Atlassian and Atlassian team.

As to what you can do to help shape my priorities, if you’re participating in CDAC (i.e., you’re already shaping them! The reason Incident Management & Change Management are top of my hit list is largely based on ongoing feedback from ecosystem developers. One of the things I love about our developer community is the honest and frank discussion about concerns broadly impacting our Ecosystem. Many of you are already secretly famous within Atlassian, as I and the rest of DX routinely screenshot CDAC posts for internal presentations and link to them in Jira tickets and Confluence pages to help foster developer empathy and advocate on behalf of you all. So please keep up the candid feedback! If you have specific topics you’d like to discuss or call my attention to, feel free to DM me or @mention me on a post any time :slight_smile:


I do have a soft spot for the “meta” apps and developer tools that you’ve developed over the years Daniel (e.g. Customizer and the Web Fragment Finder) partly because they’re really useful, and partly because they’re such a cool use/borderline-abuse of some of the unique extensibility patterns that our app platforms support.

I have a hard time picking between commercial Marketplace apps, because there are so many incredibly slick and powerful user experiences out there built by our partners that often eclipse our core product functionality. To maintain neutrality, I’ll talk about a couple of cool ones that are now (sadly) defunct :wink:. One I thought was a very cool use of the platform was the old Aerobatic app for Bitbucket Cloud. It was super-slick, tightly integrated static-site deployment tool that was incredibly well thought out and blew our own and our competitors static site hosting out of the water. Another one that springs to mind that was highly imaginative and made my jaw hit the floor was the tech demo of K15t’s “Bobbleheads” at ShipIt Live in 2017, which I think made it to Marketplace for some time.


Yes, and I agree that the current outages are not acceptable. Platform, Marketplace, and API Stability and Reliability is a key theme that Developer Experience are leaning into (and my current #1 priority) in partnership with Marketplace Partnerships, Engineering, and Atlassian’s Reliability Process Group. We’re aiming to not only reduce incidents and duration, but also to improve the partner experience during incidents by working with our incident managers to promote faster, more accurate communication. We’ll be sharing more on this front in the coming months.

1 Like

I can’t disclose the next App week location or time yet . But it is in the works :slight_smile: As a hint: the proposed location is an order of magnitude less travel time for you than it is for me (for readers: Daniel is based in Sweden and I’m based in Australia). Everyone at Atlassian is very keen to make this happen, and the Developer Experience team in particular are firm believers that one of the best ways to build mutual empathy is being physically co-located with plenty of code, coffee, and beer.


Well spotted :slight_smile: and love that you’re keeping an eye out for new Forge developers despite being an Ecosystem veteran yourself. The team that built the Renovate integration are the team responsible for Forge’s Jira extensibility and owns a subset of the Forge example apps. The engineer in question isn’t online as I write this but let me follow up with them and get back to you.

I agree our example apps have often not been well curated and maintained in the past. Currently each app is owned by the team or individual Atlassian that initially produced it to demonstrate an aspect of Forge. Although we have some standards and processes to maintain them, there is certainly a varied level of love and care applied. I agree this is likely a stumbling block for new developers that is worth more investment.


Depressing large enterprise-y reasons I’m afraid. The templates shifting to an internal service is due to the fact that Bitbucket Cloud is fairly locked down these days for security reasons and most public Atlassian repositories have been culled or made private (including all of my own!). The security reasons are fairly reasonable as corporate security policies go: Atlassian used to be very “open” with a lot of public repositories, and occasionally Git repositories can contain sensitive things hidden deep in the DAG. As we scale, the chance of one of our more than 10,000 Atlassians accidentally committing an AWS key or API token during a ShipIt approaches 1, so going private was a brutal but effective risk mitigation option (though it was not a popular one internally, particularly for the many folks keen on OSS).

The upshot is that the process to gain exemptions is quite heavyweight these days and the number of employees able to maintain those public repositories is strictly controlled due to principle of least privileges. Somewhat ironically, we also needed to shift to an internal service in order to be able to easily deploy new versions of the templates using Bitbucket Pipelines, again due to internal controls :upside_down:

That said, there is certainly some appetite to cut through the red tape and allow more effective contributions from and collaboration with our developer community. There have been some recent discussions in the Forge Build team off the back of some recent offers to contribute from a few Ecosystem Forge developers. I’ll follow up with Build and find out whether there are any concrete plans at this stage.


Excellent suggestions, and I agree that the lack of a functioning Bitbucket Pipelines template or documented tutorial for CI/CD is a glaring omission. To be candid, I suspect the omission in the docs is at least in part because implementing a Forge CI/CD pipeline is a bit awkward due to Forge’s current lack of Multi-User App Ownership (i.e. only a single Atlassian account can run deployment commands for an app) and Bitbucket Pipeline variables are not a safe place to an API token that is private to an individual. Endorsing sharing a personal API tokens in a shared context is not ideal without some strong guidance around the risks—which we should also amend on that blog! That said, it is quite an omission that we don’t have this publicly documented in some form, I’ll raise this with the team.

But yes, the Forge team have Multi-User App Ownership on the short term roadmap and also plan to support “container tokens” at some stage, which are purpose built API tokens that are bound to apps rather than users and will allow CI/CD jobs and other programmatic consumers to run Forge commands.


Great question! Interestingly the (relative) lack of in-house development in Cloud was one of the key reasons we kicked off the initial “EcoSpike” project which evolved into Forge. Back then we were seeing vastly more in-house developers creating successful apps with P2 on server than they were using Connect in Cloud, even controlling for relative population size and other factors. Our Research & Insights team have recently been digging into in-house usage of Forge and adoption and feedback seems to be quite positive. I’ll follow up with them to see if there are some stats or insights I can share.


Excellent question. As a long-time Atlassian who has never operated a Marketplace vendor account, I’m a little ignorant of some of the partner facing features there, and the fact that there’s a distinction between the data available to commercial and free apps is something I only discovered relatively recently. Let me follow up with the Marketplace team to see if I can get a bit more detail on the rationale and if there are any plans in that area. Anonymised or partially anonymised contact platforms are very popular in two-sided marketplaces so it seems like a very reasonable request.


Sandboxing is one of the biggest challenges in Cloud, both in terms of frontend extensibility for both Connect and Forge, and the runtime environment that Forge app code executes in.

Server/DC is the ultimate in flexibility because despite all the OSGi Java classloader security magic of P2 and some valiant attempts at creating comprehensive Java APIs and the occasional frontend JS APIs, P2 plugin developers can really get away with doing practically anything they want :slightly_smiling_face: Since customers host their own instances they can run whatever testing and verification of P2 binaries they want, and firewall off their servers if they’re worried about security or data privacy.

In Cloud, it’s much more complex. For security and stability we have to sandbox third-party code on the frontend, usually in iframes or in Forge’s declarative UI Kit, both of which are far more limited than the freedom of P2. Due to Forge’s strict isolation and security model, we also have to sandbox Forge code on the backend, which has a significant impact on the developer experience. Both of these are also massive (and fascinating) technical challenges because we’re really using iframes, AWS Lambda, and certain V8 primitives for use-cases that they were not really designed for in the first place. If you’re curious, Adam Strickland from AWS spoke a bit about our use of Lambda at Dev Day '22. Fortunately the Forge Build team are working on improving our sandboxing approach at the moment to bring the Forge runtime back to something much closer to vanilla Node.js, which should dramatically improve the developer experience on a number of fronts.


Ok, I’m going to post a few questions that are going to call out Atlassian as a company, not you or any of the individual Atlassians, and would love to hear your opinion about them (even if they did not lie within the responsibilities of your current or past roles)

  1. As Atlassian Marketplace Partners, over the past 5-10 years, one of the biggest frustration has been inconsistent communications (both in terms of the actual comms as well as the quality of the comms). We’ve been told over and over again that this is an area in which Atlassian was going to improve. The latest effort is currently under way to restructure comms. Given the less than stellar track record, can you elaborate on what Atlassian has done to ensure this time it will actually improve?
  • What checks and balances are in place (how will you measure success)?
  • To what extend is comms improvement part of OKR’s, not only for MPAC marketing team members but also for senior management (incl. Engineering department)?
  • What is your contingency plan for making sure that if you fail, the marketplace partner community will not completely loose faith (as the current levels are almost near non-existence)
  1. There seems to be a tendency within Atlassian to never actually admit wrongdoing. There are always a lot of reasons as to why things are going wrong, and as Marketplace Partners we are well aware that it is never the intention to make things difficult for us. However, it would really help if sometimes Atlassian (as a company) would just say: sorry, we messed up. Do you recognise this sentiment and do you think this is something you can advocate for within Atlassian.
1 Like