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.
4 Likes
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 
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.
3 Likes
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)
- 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)
- 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
-
I have often made comments about the fact that Atlassian messaging with regard to Forge and Connect is misleading. I have even asked wether or not It’s time to start being open to the idea that Forge may have been a mistake. What is your view on the positioning of forge and the fact that it is taking a big toll on the Marketplace Partner community?
-
We are often told that a lot of decisions within Atlassian are data-driven. That means that changes that might seem like obvious and quick improvements to us partners will not get the attention they deserve. For instance [FRGE-515] - Ecosystem Jira created in Oct’21 which resulted in the decision to implement We're removing the allow access prompt for Forge apps which is tracked in the Removing the Need for User Consent Trello card, are not getting top priority because apparently the data tells us that the friction it causes with users is not big enough. In my experience, data driven product development can lead to a culture of fear / indecisiveness as people are reluctant to make decisions unless they have enough buy-in. Is this something you have experienced / recognise within Atlassian product management org? And if so, is this actively being addressed / is this something you are (trying to) address(ing)?
-
Can you please shed some light on what the hell is happening with AtlasKit? Because the marketplace partner community is in an existential crisis over which frontend libraries to use
2 Likes
Great questions @remie! Happy to share my candid opinions, but it’s getting close to midnight in Sydney and I want to give your question the consideration it deserves. Let me get back to you on this thread tomorrow. (Sorry for the non-reply but didn’t want to leave you hanging after replying to everyone else’s questions)
3 Likes
Haha, I guess @Bentley never specified on which September 7th the AMA would take place 
3 Likes
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)
Well, I did say Ask Me Anything, so I’m game! 
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?
For this question I’m more than happy to personally opine on two aspects of communications that I’m currently working on, in particular communications to partners during incidents and technical platform change communications (i.e. the changelogs). I’ll refrain from commenting in detail on the broader Marketplace Partner communications initiatives that I’m not contributing as heavily to as there are several other Atlassians working very hard on that and I’ve been more focusing on the technical side of comms so there’s a high risk I’ll mis-portray their efforts. The best reference is this page on the partner portal (if anyone who does not have access to the partner portal is interested let me know and I’ll share a summary). For what it’s worth my personal opinion is that we’re taking improvements to those communications very seriously as well.
What checks and balances are in place (how will you measure success)?
Ideally I’d love to have quantitative measures for the communications I’m working on so that we can objectively measure and improve. While we have great quantitative measures for the incidents themselves (number of incidents, Time To Resolution, Service Level Objectives), we’ve found it harder to define a good measure for partner sentiment towards incident communications. We may end up with proxy measures where we interview partners to come up with a definition of “good” (e.g. incident updates with X, Y, Z details are posted within the first X minutes and updated every X minutes) and then measure how often we hit “good”, or we may end up with something more subjective. We’re actively discussing this at the moment so would love your thoughts if you have any ideas in that area!
Do what extend is comms improvement part of OKR’s, not only for MPAC marketing team members but also for senior management (incl. Engineering department)?
We have several KRs that track partner sentiment that are reported on to senior leadership. Incidents are part of those KRs, but we don’t yet have KRs defined for incident comms or technical change management comms as we’re still trying to figure out exactly how to measure that effectively. Atlassian R&D operates on a “triad” model (shared leadership squad of Engineering + Product + Design) so these KRs are consumed by multiple functions rather than just Engineering.
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)
I don’t think there really is a plan B. We’re all aligned internally on the fact that we need to improve our comms so I think we have to iterate and persist until we have a scalable and effective model that satisfies our partners.
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.
It’s a reasonable question, but it may take an organisational psychologist to answer it properly. My initial reaction was that I feel like I’ve apologised to partners for quite a few things over the last little while Though reading back I realise that while I’m usually acknowledging that we’ve messed up, I’m often not actually apologising. Instead I’ve used phrases like:
“I agree that the current outages are not acceptable.”
“The wording in both the CDAC post and the changelog entry are not great…”
“I agree this is an unfair and unrealistic notice period. We’re treating this as an incident, and have paged the team involved…”
Introspecting, I think I would feel a bit weird prepending this with a “Sorry” because I’m apologising on behalf of another team or team member, and that feels a bit weird because Atlassian operates on a “blameless culture” where we treat problems that arise internally as issues with processes that we should improve rather than the fault of an individual. This is a useful way of thinking in most contexts, because Atlassian is at a scale where processes that allows one individual or team to make a serious mistake, mean that others will almost certainly make that mistake in the future. Usually mistakes are made because someone who is otherwise wonderful and talented was missing some context when they made a particular decision.
On the “we messed up” part, I try to be as transparent with partners as possible and like to think I’m pretty comfortable acknowledging mistakes. However, I am probably in a bit of a privileged position in that I have enough tenure at Atlassian and context for Ecosystem to be able to talk fairly transparently with partners without having to go through heavy alignment processes internally to make sure I’m saying something that is accurate and (hopefully) empathetic to partners. I think for a relatively new Atlassian—or one new to the Ecosystem space—it might be a bit harder to apologise in a timely manner as you may have less ready context for why the thing that you are working on has offended external parties. Everyone on this thread is an ecosystem veteran of some sort, and it’s sometimes easy to forget just how complicated this stuff is if you didn’t spend a significant part of your life building apps on our various platforms.
3 Likes
I have often made comments about the fact that Atlassian messaging with regard to Forge and Connect is misleading. I have even asked wether or not It’s time to start being open to the idea that Forge may have been a mistake. What is your view on the positioning of forge and the fact that it is taking a big toll on the Marketplace Partner community?
I agree our communication regarding Forge has not been consistent and in some cases is downright confusing. As to why it’s been confusing—there are a few reasons for this, including the fact that Forge strategy has changed significantly in response to Atlassian’s continuing emphasis on migrations to Cloud and as we uncover more data regarding customer and partner requirements from a hosted ecosystem platform. Some of these are sensitive topics that relate to security and data privacy concerns from customers which can make it hard to communicate certain specifics, particularly while we’re still conducting research and the cybersecurity and SaaS Ecosystem landscape is shifting around us (you may have noticed that Atlassian are not the only company investing heavily in app trust initiatives and hosted platforms).
I realise this might sound like a set of excuses, and I’m not attempting to excuse the current state of Forge messaging: more just try to share a some context around the fact that this is a hard problem and a tricky space to negotiate. We don’t treat this lightly and are trying hard to improve here. For what it’s worth, I am personally sorry that our communications haven’t been better regarding Forge, and do wish I’d been more careful reviewing or contributing to comms at certain junctures over the last few years. I know this has been frustrating for the Marketplace Partner community who are already invested in Connect. I feel doubly bad as I was also on the Atlassian Connect 1.0 team and played a role in convincing you all to invest in Connect a few years ago, which was a set of similarly tough conversations at the time.
We are workshopping Forge communications across several teams over the next few months so keep an eye out for improvements and more transparency in this area.
We are often told that a lot of decisions within Atlassian are data-driven. That means that changes that might seem like obvious and quick improvements to us partners will not get the attention they deserve. For instance [FRGE-515] - Ecosystem Jira created in Oct’21 which resulted in the decision to implement We’re removing the allow access prompt for Forge apps which is tracked in the Removing the Need for User Consent Trello card, are not getting top priority because apparently the data tells us that the friction it causes with users is not big enough. In my experience, data driven product development can lead to a culture of fear / indecisiveness as people are reluctant to make decisions unless they have enough buy-in. Is this something you have experienced / recognise within Atlassian product management org? And if so, is this actively being addressed / is this something you are (trying to) address(ing)?
Can you share a reference for the “the friction it causes with users is not big enough” because I am happy to go and personally advocate to change the author’s mind if they still hold that perception This feature is a personal peeve of mine (and many internal Forge developers) and the number of reports we get from partners relating to it is significant. The reason this hasn’t been implemented yet is largely due to the fact that the solution is unfortunately significantly more complex than it appears. Forge uses Atlassian’s OAuth 2.0 infrastructure for authentication and there are some gnarly dependencies that span several critical services relating to modifying the consent flow. The team best suited to making the requisite changes have been working on some other important initiatives that unfortunately are higher priority in the shorter term, but this should be implemented soon (I’ll follow up and see if I can get a fresh update on the ticket of when “soon” might be).
As to your second question — I haven’t personally observed issues with too much data causing indecisiveness with prioritisation. If anything I’d love to give our product management team and engineers more data to prioritise and design features effectively. One of the difficulties of building a hosted platform is reasoning about Marketplace Partner requirements because Connect is so completely unopinionated about architecture, which is why we are very much in debt to those who are building apps on Forge today, experimenting with migrations and harmonisation, raising issues, and providing feedback 
Can you please shed some light on what the hell is happening with AtlasKit? Because the marketplace partner community is in an existential crisis over which frontend libraries to use
I can’t in the context of this AMA as I don’t have enough context to give you a meaningful update, but this topic is high on my hit list of topics of concern. I agree that AtlasKit, AUI, or something like it is going to continue to be important for app developers regardless of the platform they use in both Cloud and Server. Atlas Kit has previously had a bit of an idiosyncratic ownership model internally at Atlassian which has caused some strife internally from time to time and this may have contributed to the current situation. Let me dig into this with the rest of the Developer Experience team and get back to you.
7 Likes