Can we please talk about the DC annual app approval process? And more specifically, the fact that it was changed overnight from being extremely lenient to extremely strict?
Up until this year, one could simply ignore the ECHELP ticket up until the due date, ask for extensions and push the approval process to last for more than a year before Atlassian finally started threatening to remove the app from MPAC.
I admit that this is not ideal, and extremely lenient to a fault. I will be the first to acknowledge that this process needed to be improved. And so Atlassian did. But now the process is this:
sent a reminder email 60 days in advance
if the marketplace partner did not provide all required data on due date, close ticket and remove app from MPAC (within 24h)
Even if you provided some of the required artifacts, as soon as you hit the due date, the app is removed. No intermittent reminders, no last changes, nothing. One reminder, that’s it.
Removal of the app can have serious consequences for partners and is a step that should not be taken lightly. Of course, Marketplace Partners should abide by the rule that annual approval should be done before the due date. But going from extremely lenient to extremely strict overnight without an announcement, a transition period and proper communications (i.e. more than one warning email) is a bit of a dick move to be honest.
I’m sure there is a middle ground here where we can improve the process to make sure Marketplace Partners comply with the rules without catching them off-guard and that also includes an acknowledgment from Atlassian that she did not manage expectations well in the past.
The cause is the non-fixed yearly date. If you submit early, you’re fucked the next year. Example:
My renewal is on January 30th,
Tests take 15 days, but may take 3 weeks more if you need to rearchitecture something,
If I perform all my tests and submit on January 10th,
Then next year I have to have a successful submission by January 10th, so meeting my family over Christmas is out of question.
I know that because my deadline used to be in March, which gave me time, and now I can’t take winter holidays without having major uncertainties about this DC approval,
Solution 1: Vendors submit as late as possible, to not face calendar challenges next year.
Solution: Make it possible for vendors to submit 2 months early, and keep the deadline at the same date of the year.
It’s only 3 more years to go, so maybe Atlassian can offer us this present.
In previous years we would start our testing as soon as the ECOHELP ticket was raised, and submit as soon as possible after testing concluded.
That was until we realised we were short-changing ourselves by up to two months, so that “annual” cycle was more like “10 monthly”.
This year we’re holding off until just before the deadline to maximise the period our app is approved, but the risk is that (for whatever reason) Atlassian rejects our submission and we’re not approved by the deadline. (Not that we’re expecting that, but as with any approval process, you’re at the mercy of the approver).
100% the approval date each year should be fixed at exactly 12 months since the last approval; and submitting earlier that this should not bring forward that date.
Or just scrap the approval program altogether, since we all know it was only implemented as an additional differentiator between DC and Server (I remember a time when “DC compatible” was just a checkbox).
Now that Server is consigned to a footnote in the history of Atlassian, and DC is winding down with customers actively migrating to Cloud (or off Atlassian completely), why not give marketplace vendors some of this time/effort/cost back to deal with the forced Forge migration or the many other changes that we’re constantly asked to attend to.
I also think the new automated process is overly strict. Our story:
One of our DC apps was automatically hidden in Marketplace because we erroneously answered a question in a way that the automated process didn’t like. No clarifying question by an Atlassian technician; no mention of the harsh consequences; no time to correct the answers. Just auto-hidden immediately.
To fix it, we had to redo the whole initial approval process – not the yearly questionnaire, I’m talking about the big questionnaire when initially releasing a DC app to Marketplace.
We talked to our TPM for a more lenient solution, to no avail.
I see what you mean. For the question “Did you review the app’s 3rd party/open-source dependencies for vulnerabilities using automated tools? and, do you plan to keep these dependencies up to date?” I answered No, because we do it manually, rather than automated. And now we have three apps set to be archived.
Atlassian have generally been at the forefront of how not to automate your support, but this takes the cake. Especially since two of them have until the 13th Dec to finish. The apps will be well and truly archived by then
Uh oh, this sounds like a dick move indeed. I remember that every single time we had to to the approval we were asked whether we had tested the app against all the different databases, which, surprise, we did not because we don’t even interact with the database directly and I’m sure not going to pull up a testing stack with Oracle DB, and so we came up with a manual explanation (I mean, this is not even part of the requirements). I’m kind of worried these kind of issues will suddenly delist our app as well.
We also do not automate the dependency checking (okay, if looking at the maven output and running npm audit counts, we actually do), but do this manually and have no intention to change it.
The only “improvement” we’ll see is that developers will blatantly lie about the security questions, because why bother - if Atlassian finds out, the worst that can happen is that you get delisted anyway.
Suddenly I know how Roman slaves must have felt when the galley they were cahined to was sinking…