Calling All Cloud Developers

Hey folks! I’m Simon, one of the Product Managers for our cloud ecosystem platform.

Every day, I get to work with an incredible team that’s doing everything they can to make our cloud developer experience delightful. A big part of achieving that is your feedback - and we care deeply about ensuring it’s considered as a part of our roadmap.

To that end, I’d love to hear how we can improve Atlassian cloud development for you.

What’s the one thing that would make a difference in your experience working with our platform and APIs?

(I can’t make any assurances that we’ll action your ask, but I can promise that I’ll get a response to you for taking the time to share feedback with the team.)

I’m super proud of the passionate community we have here, and I’m looking forward to reading your responses! :rocket:

20 Likes

Be careful what you ask for :slight_smile: : Reliability.

Reliability in the sense that the (both frontend and backend) api’s shouldn’t be randomly change/break (from our perspective) every week. (It’s gotten better but it still happens).
Reliability in the sense that the documentation should usable (try using the REST api - the User Experience is awful nowadays for example)
Reliability in the sense that when we have a real issue or question, we can reliably reach out to Atlassian in one place and get things resolved/answered in a timely fashion.
Reliability in the sense that when there is an announcement - it’s posted in a single place and not spread out across multiple systems/pages.

Be more than happy to chat more about any of those above.

Featurewise - there are umpteen discussions on this forum about things that would be great for us to all to have. If I had to pick one feature feature - Encryption keys on a per app/tenant which Atlassian manages so that we can do a per-tenant encryption (which btw - the security team really wants us to do)

27 Likes

Hi Simon,

For me it’s a two-part answer: answering questions, and fixing bugs. I don’t know if that’s something you wanted to hear. As a Product Manager, you may want to hear that we want a Thing, a tool or whatever that your team could provide to the Ecosystem. Those things are nice, but what I need is your people. I need someone to get me unstuck when I’m stuck, or make the broken-ness go away when my own product is relying on some product feature or API.

So just get all available Atlassian developers to participate more on these forums; and get them to fix the bugs we find more swiftly. I know that’s not easy. It’s simple, but very far from easy. It’s also the truth.

Thanks for asking the question. That means something too.

David

18 Likes

Reliability in all the ways mentioned above.

5 Likes

Hi @SimonKubica

I am not sure if suggestions bellow are relevant to what you are asking, however as app developer these are things that would really help us.

  • App approval process and time: currently Marketplace app approvals taken 10-12 days and sometimes a lot longer. There is no information whatsoever when an app can be approved. It’s basically submit for review and wait wait wait. There are other threads in this forum about it. As far as we understand, app approval team is very small. Wish something could be done about it.
  • We often have API requests which we don’t know where to submit and even if we submit, I am sure if they are looked at. Some examples are: API for Confluence decisions (similar to tasks), Panel for Service Desk requests etc. Feature requests portal especially for app developers would be great and I think overall would really help to improve ecosystem apps.
  • Atlassian Connect Express for other popular languages like Python or at least supported SDK

That’s all that comes to my mind for now.

3 Likes

All of the above, and:

Accountability
Whenever you make changes, we need you to be available, to listen, to digest our feedback and to tell us if and how you have adjusted accordingly. We need the background information that drives your choices, we need to know that you’ve listened to our feedback, that you have considered it and that you tell us why you are making other choices in case you decide not to act on our feedback.

6 Likes

I feel the need to reiterate the communication, support, reliability, and accountability points. +1000 to those.

If I had to pick only one thing of the great many pain points that make cloud app dev anything but delightful today, it would be the poor developer support. I still can’t believe that a company who makes the lion’s share of its revenue from Jira and JSD uses CDAC as a primary developer support system.

I wrote up several other more concrete pain points and then realized you only asked for one :smiley: I’d be happy to share the rest over a direct message or another channel if you are interested.

4 Likes

We are frequently paralyzed by missing Jira Cloud REST API end-points, and when we submit feature requests for those, the requests land nowhere (or at least, it is not transparent what happens after).

9 Likes

I mostly agree with the guys, for me the words are RELIABILITY and VISIBILITY

We all work in both sides of the “spectrum” under some stable facades. In our everyday we sometimes see how there are bugs, or things we do wrong we have no means to track or an easy way to debug, which in the end translate into long support issues

It’d be very helpful having a way to track at least our interactions with Atlassian product, things so easy as “why an event is not coming”, “conditions”, etc etc end up in an endless try-catch process, sometimes just to find out there’s a bug somewhere

5 Likes

Unlock reading basic configuration which is already available in Jira. Make it possible, so that apps could respect Jira settings. Most basic example is date/time format settings.
Each time we want to release a new app it is a struggle to respect Jira settings. Our customers also struggle and don’t understand why the date format, they set in Jira, is not working and why they need to configure it once again in another place.
In this case, there is already an endpoint in Jira, however not listed for apps. Such a simple thing, would change the way we design cloud apps and would remove the need to build custom UI in apps just because there is no way to respect settings that are already there.
https://ecosystem.atlassian.net/browse/ACJIRA-1952?filter=61665

I would also love seeing Jira respecting its own settings! but that’s another topic.

4 Likes

My #1 genie in a bottle wish is:
**A true advocate for the Atlassian Cloud ecosystem development whose top priority is helping vendors to make the Cloud platform truly great for vendors and customers. **

It feels like this is a ‘role’ of several people, but not in anyone’s top three priorities. ( Please correct me if I’m wrong )

Let me start by saying once we’ve been able to get a hold of someone at Atlassian, set up a meeting or otherwise engage them the interactions have generally been very helpful and productive.

I would love it though if the Atlassian Cloud teams cared about the ecosystem as much as the Atlassian Server/DC ecosystem teams.

As an example, when the Atlassian server teams are releasing a major new version they actually test ecosystem apps, report problems and even offer to roll our apps into their integration tests!

By contrast the Cloud ecosystem will roll out breaking changes, basic test coverage feels limited (can we see the integration test coverage of the REST API?)…and when things break it feels more like our problem to find, escalate and then communicate with customers who think its the vendor’s fault…which it almost never is. We’ve gotten some decent post incident reports from Atlassian but that can take many weeks with little communication in between. And I’ve definitely appreciated the follow up meetings and attempts to improve.

2019 was an extremely painful for Atlassian 3rd party Cloud dev between the Fabric editor, breaking changes rolled out pretty frequently, GDPR (had to be done), multiple security program initiatives (very important, but Atlassian pushes common work here to vendors quite often).

It doesn’t feel like the vendors/developers on the Cloud ecosystem have a true Atlassian advocate that’s on the side of vendors despite articles about the MarketPlace surpassing $1B in revenue. Do we?

I DO believe that some of the Atlassians do in fact “care deeply” and it often shows. They just have many other priorities thrust upon them and ecosystem health doesn’t seem to register on top. Despite the fact that just from our company alone Atlassian’s portion of our revenue could pay/hire half a dozen people our inquiries on DEVHELP often sit for weeks or months or more. AND sometimes we get awesome fast service, it is unpredictable.

I would like to add ‘much respect and mad props for asking this question!’. It feels like a step towards my ask.

7 Likes

Hi @SimonKubica,
I’m afraid you’re going to get an overwhelming number of different replies from the ecosystem :slight_smile: I believe the general sentiment among vendors is that Atlassian has invested way too little into the ecosystem over the years, and now that Atlassian is a billion dollar company, it has become… bewildering.

If I have to pick one problem I’d like to see fixed, it’ll have to be: close the gap between Server and Cloud APIs. Which I understand is impossible, because of the major architectural differences. But at least create a “stream” / team / whatever works for Atlassian dedicated to implementing the (REST) API feature requests that come from Vendors - especially the “small” ones, those that would require a very small investment to implement (hours or days). There are way too many requests that have been pending for years, and that are preventing us vendors from offering feature parity between our Server and Cloud apps.

11 Likes

Over that last week or so we have run into two serious issues that is causing blocking problems with people evaluating our products. One already caused somebody leaving a negative feedback in Marketplace.

We submitted the tickets, made tons of noise, got some attention. First issue just got fixed. Not explanations given, we were just told it was fixed. Maybe it wasn’t fixed? What do you think we can tell customers and potential evaluators?

Second issue, they cannot be reproduced, and we werepretty much being told there’s not too much it can be done.

When asking for some help for troubleshooting or at least understanding WTF is going, we were told that well, there is yes, there is frequent releases going on…

This is not good for us. And not knowing what’s going on makes it very difficult to respond and to meet our cloud goals, which BTW, are now the most important parameter for determining Marketplace Partners tiers.

Atlassian long term visions of to get Server customers to move to Cloud, but wan we seriously ask our customers to move to Cloud where issues like these appear and disappear without explanation and that it’s a side effect of Atlassian releasing very frequently?

With issues like this all we can say is “oh well, not our fault, Atlassian is looking into it, it may or may not happen again”. Very little we can do.

I believe Atlassian needs to ramp up the way it supports Marketplace Partners.

Here are some ideas:

  • To come up with a protocol by which paid customers and even evaluators (and free licensees) could share their back-end logs with a Marketplace Partner. We can learn a lot by looking at the logs ourselves and help with troubleshooting
  • To formalized the protocol for Marketplace Partners to come up with dev issues, including having a common instance with all permissions required. Neil has something like this already, let’s make it more formal.
  • Enable a ‘Developer’ mode in cloud instances. A way to get logs immediately, verbose modes in Front End, entry points or something which could help us learn more about issues.

These are just our ideas, I am pretty sure other Marketplace Partners have others.

But it comes down on Atlassian giving the push on Marketplace Partner Support to meet both Atlassian’s and our own Cloud goals.

I believe Atlassian cannot meet their 3-years Cloud goals without getting the Marketplace Partners on board and giving them the ability to support our shared customers.

6 Likes

Thanks for reaching out to the community @SimonKubica. This is a sign, I believe, so many vendors have been waiting for from Atlassian. I am afraid I guess many answers will go beyond your question because there is a lot more broken than just the platform or API experience.

I agree with everything that has been said by others. In addition to that, I would like to highlight an issue with Atlassian Connect frameworks.

Atlassian officially offers two Connect implementations and I would like to focus in particular on atlassian-connect-express. The state of this project seems questionable to me to say the least. There have been no real Atlassian contributions to this repo for more than half a year, the repo has 10 open pull requests, some of them as old as 2017, and the project’s Jira board seems to have been frozen since mid 2019. Changes that have been merged since last summer are all vendor contributions (some of them security patches to comply with Atlassian’s security guidelines!).

How can such a big company that takes 25% of vendor-generated revenue to (hopefully) fund development of such essential platform tools, neglect a project that much? I understand that it’s all about Forge now for Atlassian but they seem to forget that there are thousands of vendors relying on the existing tools. How can a project so essential to a platform be abandoned like this and how can Atlassian simply leave it up to the community to maintain a project (without giving them actual control over it or involving them)?

I think you can see where I am going with this and I believe it reflects the same feedback many others already gave from yet another angle. Atlassian seems to be more and more focused on itself and detached from the ecosystem.

7 Likes

Hi @SimonKubica,

Totally on board with all the non-feature request points that everyone’s raised. But if there was one thing in the actual platform that’s incredibly frustrating is that the only good way to enforce permission checks on our connect servers is by using the /mypermissions endpoint with user impersonation. If we could fetch a user’s permissions without having to pretend to be them, we’d have less need for the scary ACT_AS_USER scope.

/rest/api/3/user/permission/search does exist but the mental model is backwards and only supports permission 1 AND permission 2, not permission 1 OR permission 2 as our use case has been.

Regards,
Satvik Sharma
Developer, Easy Agile

4 Likes

I think you’ll find the issue here is a bit of a two way street where vendors don’t use ACE, so they don’t care about Atlassian supporting it.

1 Like

Absolutely, apologies if I spoke too much for other vendors, but I think Atlassian should care. Reasons why other vendors did not choose the express implementation may be varied but I guess project status and quality is certainly one of them. The two framework implementations are the entry points for everyone new to developing apps on the Atlassian Cloud platform. I would expect them to be in top-notch condition at all times until Connect is officially not supported anymore or discontinued.

7 Likes

Oh, I’m totally with you that ACE needs to be invested in more heavily by Atlassian, we use it! I’m just saying, that with plenty of vendors rolling their own, the demand hasn’t been there.

2 Likes

Oh I’ll disagree - the demand on the vendor side is there. Even if you roll your own - having a reference architecture is a must…

Unfortunately like most Atlassian projects that they provide to vendors, it goes off into a corner and slowly dies as Atlassian loses interest or just becomes an internal project (cough Atlaskit cough ).

5 Likes

@SimonKubica
I totally agree with @tbinna that ACE as an officially supported Connect framework needs to be actually supported. We’ve run into issues with the framework and Atlassian’s examples. Even not all pull requests get acknowledged.

And I second

3 Likes