Welcome back to our Developer AMA Series! For our second installment, we’re excited to host @tpettersen. After several years as an Engineering Manager on the Forge team, Tim recently stepped into a new role as Head of Developer Experience at Atlassian.
Throughout his career, Tim has interwoven platform engineering, developer advocacy, and evangelism. He’s played key roles in developing three generations of Atlassian’s server and cloud ecosystem platforms, and worked closely with the over 1,500+ partner organizations and tens of thousands of developers that build kick-ass apps on top of them. He’s at his happiest building technical products for a developer audience.
Tim is ready and excited to answer your questions about all things developer experience. Feel free to add your questions for Tim as replies to this topic starting today and he’ll answer all of them on September 7th.
If you can’t join us on September 7th, you’ll be able to review this topic in the community after the AMA takes place. We’ll also be sharing a quick recap on the Atlassian Developer Blog so you can get caught up.
Without further ado, let’s chat! Share your questions for Tim below.
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 ).
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. community.developer.atlassian.com), 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
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 . 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.
I can’t disclose the next App week location or time yet . But it is in the works 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 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
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.
).
