Sounding the alarm on the Platform 7 release, just to be able to say "told you so" 😉

General
, ,
1

Dear Atlassian,

Due to the distributed nature of your company culture, where you like to give your teams as much autonomy as possible, please allow me to sound the alarm on the upcoming Platform 7 release(s) from the birds-eye view of a Marketplace Partner.

Because you are on a fast track to absolute and complete mayhem. You may not see this yourself, or shrug it off for whatever cognitive dissonant reason you feel comfortable with, but this whole thing is one hot mess.

As with many such endeavours, the Platform 7 release has fallen victim of a feature creep of massive proportion, and it is bound to break apps left and right.

Let’s start with the fact that although this release will be massive, which should warrant a centralised approach on change management documentation, so far it has been almost impossible to keep track of all the changes. Here is a list of all the CDAC threads that contain information about the upcoming release:

RFC-24: Data Center Grey API Removal
Include/exclude list for RFC-24 Data Center grey API removal
Announcing Data Center Platform 7.0. Next step to improve our security posture
Confluence 8.7 beta is available now
Confluence 8.8 release EAP available now
Preparing for Confluence 9.0 - EAP coming soon
Preparing for Jira Software 10.0 and Jira Service Management 6.0 - multiple EAPs coming your way

When you do take the time to follow up on all the back-and-forth comments on these threads, you will find that in addition to what was previously announced in RFC-24, there are a lot more changes coming in this release. So far, we were able to identify:

  • removal of a large list of 3rd party libraries from OSGi exposure
  • removal of references to these 3rd party libraries from public API signatures
  • refactoring of (semi-)public API to exclude as much code as possible
  • limiting exposure to internal APIs
  • removal of deprecated code
  • removal of the H2 embedded database
  • switch to Java 17 as minimal supported version

And this is just the beginning, because we are now only provided with the Confluence EAPs. And because there is no clear centralised roadmap for platform release 7 (intentionally), it is not clear to Marketplace Partners when the next wrecking ball EAP will hit. We might end up with having to refactor apps for Jira, Confluence, Bitbucket and Bamboo at the same time.

Oh, and did I mention that all of this is almost impossible because you’ve chosen security through obscurity by removing access to source code (see What happened to the Source Downloads?)

Please Atlassian, take a step back and consider the impact this is going to have on the Atlassian Marketplace. You are going to throw out the baby with the bathwater. Or, to quote Queen: “you’re headed for disaster cause you never read the signs. Too much love (for platform 7 release) will kill you, every time.”

53 Likes
2

AAAANNNDDD
 there we go!

So while the hot mess that is Confluence 9 is still shaking up the Marketplace Partner Community, we are already confronted with Jira 10 EAP announcements.

2 Likes
3

We will also be removing support for the H2 embedded database.

Yet another thing to take care of.

7 Likes
4

I’ll try to express why the current communication strategy does not meet the mark from a business perspective.

We’re a large group of companies, with multiple platinum marketplace vendors in that group. I personally represent the ScriptRunner part of the business, and communicate internally to other business units.

There are several globally distributed teams working to support our Data Center apps. Despite the cloud first world we live in, our Data Center apps are not in maintenance mode, and receive continued investment including new features and functionality.

We ship new Data Center versions of our apps every two weeks, consistently!

Like any large business, we have OKRs and roadmaps planned well in advance for the financial year. We had factored in Platform 7 as a large disruptive piece of work, with unknown scope til a later date.

Internally there are very few engineers who actually read CDAC, and even fewer non engineering product team employees.

My job is to take all the information Atlassian publishes here, and work with our product teams to put in place roadmaps, our goal internally is to be compatible with all new versions at most 2 weeks from their release. (My personal goal is to be compatible on release day).

At this moment there is no centralised list of downstream breaking changes for Platform 7. The posts around Confluence 8.8 and 9 are not clear with their intent, with several suggested breaking changes as @remie notes, and others which you have to read between the lines to see.

How do I as a leader in my product organisation put forward a clear list of required work to my colleagues? Right now I cannot do that, I can link them to various CDAC threads, however understanding the actual scope of work required is a tall order from the back and forth discussion.

And we haven’t even got to the other apps yet, there is chaos already just with Confluence.

May I suggest that documentation about all breaking changes is centralised in a source of information that is not CDAC? Anything that vaguely could be a breaking change should be documented.

In an ideal world Atlassian would also propose workarounds for breaking changes, including how to manage cross-version compatible apps, but I know there is a slim chance of anything like that.

For example, where is a list of the OSGi packages being removed from every product? Likewise where is the list of public method signatures that will be removed/modified from every product, including their platform dependencies?

To Atlassian these may be independent teams, however for other businesses their app portfolio spans multiple products, often with shared codebases, so ideally the work is done all at once for all impacted apps.

Right now I am faced with the difficult situation that we may have to delay our Platform 7 compatibility work, as it is nigh impossible to front load the required work, due to a lack of information from Atlassian.

36 Likes
5

As an operator/administrator/developer of SpaceX’s internal data center tools with 15k users and many plugins from Vendors and internally developed plugins, I do admit this is all rather difficult to sift through and certainly concerning. We only upgrade to LTS and often only shortly before the previous LTS is out of support, so I am mostly just hopeful that this all gets sorted before that time frame would come along.

15 Likes
6

Thank you @remie for starting off this thread. Firstly, +1 on everything everyone wrote on this thread.

Refined has had apps on the Marketplace for over a decade. During the years we’ve seen many versions of Jira and Confluence, many initiatives, changes and programs. But we haven’t seen anything like this before.

For us, the big problem that is also highlighted in the comments above, is that we do not know what all the coming changes mean to us. This is mainly because we haven’t been able to even find all the changes that you’re planning to do. The information is scattered in Maven repositories, random comments in threads on the community or in a (vendor) Slack channel somewhere.

There’s issues happening that’s seemingly outside what’s been communicated - e.g. We used xwork for actions across Confluence 7 and continued with it in Confluence 8. But now in 8.8 this doesn’t work since you do additional updates to struts (the replacement). There’s more levels to it - even if you do manage to replace the old APIs with new - newer are not providing the same functionality and aren’t documented.

We’re now spending time on seemingly basic things like how to get a page by id or a space by space key. It is unacceptable that the vendor community has to spend time on things like this.

So our request is this: For each class being removed/made not public - mark it as deprecated and for each method of each class - annotate what alternative to use and how to use it.
For actions/struts/spring/rest whatever, on the build-level. Specify for each removed package how and what new package to import /add dependency on, and ideally how to set up OSGi to resolve imports of both packages to allow cross-version support.

I fully understand that maintenance is part of SDLC but this goes beyond maintenance.As we’re focused on cloud, the same team who needs to deal with this is supposed to build for cloud. Our plans for the team are now going down the drain as we have no clue if this will take us 2 weeks or 2 months.

Build with heart and balance - where is the balance in all of this?

19 Likes
7

Oh, and did I mention that all of this is almost impossible because you’ve chosen security through obscurity by removing access to source code (see What happened to the Source Downloads?)

Agreeing with @remie’s concerns, I want to shed light on the fact that Atlassian has also stopped sharing the source code of the (Ex-)Open Source Atlaskit components, which has been mentioned here in November.

Those questionable actions make adopting the many platform changes even more like a hard-to-beat puzzle game as we have to reverse engineer the compiled JS Source Code (which is available anyway).

Re-enable sharing those sources (best with the Jira and Confluence DC) with your partners would be an appreciated sign of goodwill and appears like a quick fix.

9 Likes
8

Hi,

I also got the impression that this platform upgrade is less transparent than previous ones were. Maybe it is because of the coordinated release and the early communication covering only platform changes, but not product-specific API changes, or maybe I just didn’t find it, or I am expecting information at a time where it’s just not yet available.

Right now as a developer trying to understand the impact on our apps I am facing several obstacles that are not really necessary.

The main pain points are the lack of:

  • a central upgrade documentation covering not only removed packages / libraries but also shared libraries and APIs such as SAL, cache-api, AUI, etc.
  • access to the source code to see what alternatives might be available (by reading deprecation notes / inline code comments).
  • updates to the existing developer documentation. For example how to provide a REST API using the <rest> module and custom transport classes without having access to the Confluence-bundled Jackson library for annotations.

Adding more example code to CDAC is IMHO the wrong approach. This information should be contributed to the ‘official’ developer docs as the single source of truth instead, and not be buried in a CDAC thread where it’s hard to find and evaluate whether it is still relevant or not.

I also want to note that I really appreciate the efforts of individual Atlassian’s who want to help us out here and are available and active on CDAC, Slack, etc.
It’s reassuring to see you are listening to us and are willing to revert some of the changes.

Cheers,
Jens

4 Likes
9

I’m going to agree with @remie and everyone else here.

At this point we(55 Degrees) not sure if to what degree we’re affected (pretty certain that we will be). We’re planning on waiting until RCs to really dig into it. (and will be looking for documentation along the way).

More than likely this approach will mean that we won’t be able to get our compatibility in the same normal timeframe but it’s the only way we’ll be able to contain the fallout from this project.

7 Likes
10

I have three suggestions (beyond my commentary in related Confluence threads):

#1:

Atlassian needs to allocate dedicated working hours to high-level technical team members (at least one per main product) whose official role is to engage with the community about the upcoming changes, to collect feedback, track it some place central (and ideally visible to the community, such as in a public project on EAC), and be able to communicate with the community about outcomes.

I stress “technical team member” (meaning a developer with significant experience on the product platform, versus a non-technical project manager) because the vendor community needs someone who is able to directly grasp what is relevant and what is a big deal or a little deal, ask clarifying questions immediately, be able to estimate the technical magnitude of potential modifications proposed, suggest workarounds, and be able to advocate for changes internally.

Trying to funnel this type of feedback through PMs on the front line often leads to a significant loss of fidelity. This team member should have a direct line of communication to the development manager (or whoever is responsible for scheduling work and making decisions) for both the product as well as the platform team, meaning that they can be empowered (and given budget) to enact changes to the roadmap.

I have personally contributed feedback about a number of issues in the past, but it seems like some of these comments have gotten lost in the void and needed to be repeated. It is not usually clear if feedback has been accepted/integrated, declined, duplicated by someone else, or perhaps just lost. Having people dedicated to collecting feedback, as well as an open and community-visible board where we can track progress, would be really helpful.

#2:

The documentation provided here regarding platform deprecations is somewhat helpful, but one thing that is lacking is the correlation with product releases. The developer community doesn’t directly care about which “platform version” includes a change, because the platform version is mostly invisible to developers. Having the artifact version is slightly more helpful, but we still can’t turn that into something actionable without doing a lot of digging into a pile of .JARs in a shipping product.

What is important is to document when those changes are shipped (or expected to be shipped) to Jira, Confluence, and other products. Ideally, Atlassian would provide developers with a column indicating in which app milestone releases the changes are shipping (or are expected to ship).

#3:

Atlassian needs to get people on the various teams to try to rebuild significant apps against current milestone releases of products, so that Atlassian can see for itself the pain that vendors are experiencing.

Atlassian has given itself “cheat codes” so that (for example) the public OSGi deprecations do not apply to Atlassian-written plugins that have “com.atlassian” plugin keys. Given that, the impact of all of these changes are probably not yet as widely experienced within the company as you might assume.

While these cheat codes are understandably necessary to allow progressive building out of the platform 7 release, it would be great if someone were to take a non-trivial Atlassian app (let’s say, Confluence Questions), remove the training wheels and bypasses for Atlassian-only code, and see how badly it fails to work with the current milestones. I think this will give Atlassian a lot of insight into how the developer community might feel.

16 Likes
11

At Appfire, we are in total agreement with the posts here and those that have responded. I have been having these discussions with our TPM.

Marketplace place partners run real businesses, and Atlassian seems to forget that. We have annual, H1, and H2 planning that takes place well in advance. And when these disruptive changes come along, some that make sense and some that do not, we are stuck reacting instead of planning. It also very difficult to keep up. We divert our teams away from advancing our cloud apps to trying to respond to a growing list of extremely technical changes from Atlassian. And the amount of change is more than just Platform 7: Confluence V1/V2 API deprecation, Custom Domains, App access rules, Dark Mode, Data Residency
 Some are easier to manage than others.

We have been told that migration guides are coming from Atlassian to assist partners in identifying alternatives for the deprecated libraries. These guides should be coming out as part of the announcements instead of each partner solving these problems themselves.

We appreciate the fact that Atlassian is trying to be aggressive and competitive, but it’s coming at a cost to nearly all Marketplace partners. You are not just affecting our code, you are affecting our business in how we distribute and manage releases for compatibility.

We need to slow down.

21 Likes
12

I have been silently but closely following this thread, and I thought it’s time to chime in to just say that I fully agree with the sorrows and concerns expressed here. I’m pretty sure that most if not all vendors, who haven’t contributed to this thread yet, silently agree as well.

4 Likes
13

Why do the same rules not apply to Atlassian apps? I can understand those bundled with the host application having some leeway.

As I see it, any app that has a plugin key starting with com.atlassian is exempt from the OSGi restrictions.

Is this just for the EAP?

Shame I can’t trivially change our plugin key.

7 Likes
14

I’m going to add to this - source code access. We need to see what changes are actually happening.

I really feel this will be one of longest launches from Atlassian
 (ie somebody at Atlassian is at some point wonder why customers isn’t adopting this release).

6 Likes
15

I think this is really important. There are tons of apps that Atlassian has acquired from former Marketplace Partners that are big enough to feel the same pain current Marketplace Partners are experiencing. For instance ProForma: Forms & Checklist for Jira | Atlassian Marketplace and Automation for Jira | Atlassian Marketplace

@simonh / @Andreas have you been working on this yet?

6 Likes
16

+1 from my side! Thanks again, Scott, for your constructive and insightful posts. Much appreciated.

I especially agree to this point! I also have the feeling that Atlassian does not fully grasp what disruption it’s causing for (Data Center) app vendors.

4 Likes
17

Or maybe that’s a secret plan to break 90% of DC apps, so customers would finally migrate to cloud :rofl:

6 Likes
18

Hi Developer Community,

First of all, we want to thank everyone for the feedback and thank Remie for raising this topic. We’re aware of the communication gaps and we know that all the information is currently distributed across different places. We’re working on consolidating all the sources and improving our communication with you.

Right now, we’re taking a step back to prepare the first comprehensive summary of changes that we’re making within the Platform 7 release and to ensure that your migration to it will be smooth and simple

Check out the summary of changes for the Platform 7 release. Please note that this summary is rather a preview of what we’ve done and continue to do. We’ll be sharing more information with you during our work.

Platform 7 is our strategic way of dealing with increasing security issues. We understand that it might be challenging, and we all need to make an extra effort to get used to the changes. We’re committed to helping you with the migration and want to work together to make these changes smooth for all our partners. Our engineers are still finishing the changes for Platform 7. We prioritize getting a stable version of Platform 7 ready and integrated into the Atlassian Data Center products to get an EAP (Jira 10, Confluence 9, Bitbucket 9, Bamboo 10, Crowd 6) in your hands as soon as possible.

In the meantime, we’re putting together detailed developer guides for all the changes to make the migration as smooth as possible. Also, we appreciate all the feedback and are doing our best to provide clear information on what is to come. Stay tuned, and thank you for your continued cooperation.

13 Likes
19

Hi Malathi,
Thank you for this - and we really appreciate that ya’ll are listening. Is it possible to get a structured mechanism for folks to ask questions and get direct support as you start releasing EAPs and RCs? It will help to reduce the cost of supporting this new platform (I know you probably can’t speak to that right now - but please make sure that is in the discussions).

Thanks again.

/Daniel

9 Likes