While we understand the rising requests of customers for advanced native features, and Atlassians intention to feed their needs, we are concerned about the impact this development may have on the broader ecosystem. Especially for vendors who have invested significant time and resources into developing apps with outstanding (not native) functionalities.
Marketplace vendors have dedicated major effort to create solutions that cater to a wide range of use cases and perspectives, ensuring a perfect fit for customers’ needs. This level of creativity, love and passion is something that will not be fully captured by a native solution provided by Atlassian.
It is crucial that the contributions of marketplace vendors are appreciated and that their efforts to enhance the Jira/Confluence experience are recognized. We hope that Atlassian continues to value the hard work, dedication, and close relationships of its partners.
Maintain an open dialog, collaborate and remember: impossible alone. possible together.
We’re not directly affected by this RFC, but we share the concerns others have raised, including the increasing pace with which Atlassian are developing native features offered by third-party plugins, and the unfair competition that arises as a result of Atlassian having access to resources and APIs that third-party vendors do not have. To add two more examples, the (relatively) new Site Optimizer feature in Jira overlaps significantly with our app Optimizer for Jira (both in functionality and name!), and Atlassian Guard’s data classification feature is almost identical to that in our app Compliance for Confluence.
Midori is not directly affected by this particular RFC, either, but here is another example.
Our Better Content Archiving for Confluence app (a top seller on DC) served as an “inspiration” for the content lifecycle related improvements in Confluence Automation (archiving inactive pages, sending notifications to page owners, etc.), and for several new Confluence Cloud features (page status, content owner, etc.)
We are a small bootstrapped team, we invested enormous efforts (and time, money) into implementing the Cloud version of the app, scaling it to extremely large Confluence Cloud sites while navigating between Confluence REST API / Forge / Connect bottle-necks and limitations. I assume that implementing features on the other side of the platform is much much easier, therefore Atlassian has a major advantage vs app vendors.
Like others, I would also appreciate a statement from Atlassian on their strategy. Is it sensible for a small app vendor to build “something big” in 2024 and take the risk of competing with the platform owner (and fight an uphill battle)?
There have been a lot of changes lately and that’s fine when there’s a good reason behind them — e.g., a major issue with data residency, making Forge a necessary change that vendors must either adapt to or be left out of meeting this market need.
However, this time it doesn’t seem like you’re solving a real problem. Over 55 checklist apps (including free ones) already meet users’ needs. Isn’t that the purpose of third-party apps in the Atlassian ecosystem — to extend functionality and allow you to focus on challenges that vendors can’t solve?
We want to address the concerns raised in this RFC and our plans for implementing an action items feature set in Jira. We understand that many of you have invested significant time and resources into developing products that address this need, and we appreciate the value you bring to our ecosystem.
First and foremost, we want to emphasize that our partners are an integral part of the Atlassian ecosystem. Your innovations, expertise, and dedication have played a crucial role in making Jira the versatile and powerful tool it is today. We remain committed to fostering a thriving partner ecosystem and ensuring mutual success.
We recognize that the introduction of native action item functionality in Jira may overlap with some of the solutions you’ve developed. Our decision to implement this feature stems from consistent feedback from our customers about the need for basic action item tracking within Jira. Our goal is to meet these fundamental needs while continuing to provide opportunities for partners to offer advanced, specialized solutions.
Here’s how we envision moving forward:
Collaborative Approach for Future Enhancements: We want to work closely with our partners throughout this process, specifically with the Future Enhancements direction. We’ll be setting up feedback sessions and workshops to gather your insights and discuss how we can minimize negative impacts on your businesses.
Focusing on Core Functionality: Our native implementation will focus on basic, essential features. This leaves ample room for partners to continue offering advanced, specialized, and industry-specific solutions that go beyond the core functionality. The proposed solution is a basic checkbox in rich text fields that can be checked and unchecked, similar to those in Jira Product Discovery and Confluence, but without task list functionality. This solution does not include advanced functionality.
Transition Support: For partners significantly affected by this change, we’re exploring ways to provide support during the transition. This may include co-marketing opportunities, feature highlighting in our marketplace, or technical support for pivoting to complementary areas.
Advance Notice and Transparency: We commit to providing clear timelines and regular updates throughout the development process, allowing partners time to adapt their strategies and products.
Resolve this RFC on the 1st of November
Commence roll out late November
We understand that change can be challenging, and we don’t take your concerns lightly. Our goal is to strike a balance between meeting customer needs and maintaining a vibrant partner ecosystem by making our products more extensible. We believe that by working together, we can navigate this change in a way that ultimately strengthens our platform and creates new opportunities for innovation.
We value your partnership and are committed to your success. In the coming days, we’ll be reaching out to schedule individual and group discussions to dive deeper into your specific concerns and ideas.
Thank you for your continued dedication to the Atlassian ecosystem. We look forward to collaborating with you on shaping the future of Jira.
Well, I don’t think this response “addressed” any concern.
It basically means that “we will build the basic features into the core, taking away 2/3 of your market, because this is what most people want. You are left with the third of what you had before, which are the most complex, hardest to sell, difficult use cases, so your user acq costs, maintenance and development costs will rise. Your best chance is to raise prices and see if the market values your advanced version enough”.
The promises are the same “hot air” panels that we have been hearing for years now. “We will cut your legs, but don’t worry, we will teach you how to fly.”
At this point being brutally honest (even if for just a limited audience) would be the best communications strategy, instead of empty promises.
To be honest, I feel that the response from Atlassian is a bit underwhelming. Other than stating that the team will connect with partners to discuss how they can make their apps competitive with native functionality Atlassian is not offering them anything.
Not only that, Atlassian also requires the partners to reach out instead of proactively contacting them herself. What if a partners does not see this comment and miss the opportunity? I would say that noblesse oblige applies here.
Atlassian also does not mentioning anything about the abysmal communication with partners with regard to this change.
The comment does not change anything to the timeline.
It basically offers partners nothing but a completely gratuitous offer to “connect”.
I don’t think this response will restore trust from the partner community
I would like to suggest an opportunity for improvement of internal Atlassian processes:
This RFC was first published on October 15, with rollout targeted a month to a month and a half later. Based on what I infer about Atlassian’s internal processes, this means that at the time of publishing of the RFC, I have to guess that the feature was already completely designed, resources were already budgeted, allocated and scheduled, and that the implementation was presumably well underway.
This makes this RFC effectively an announcement rather than an RFC: the major decision has already been made, the detailed trajectory has already been plotted, significant resources have already been expended, the feature is relatively close to release, and it is unclear if any real feedback is being sought. The RFC does not include the standard “Actions” section (the part where Atlassian explains what it particularly wants to hear about from the ecosystem community), and the fact that this section is empty/absent is telling.
If the stated goal of an RFC is to have “early collaboration with our Ecosystem”, then this one missed the mark.
If Atlassian publishes a RFC but the comments can do nothing to influence the trajectory of the RFC, you risk alienating your ecosystem partners because commenting seems futile. A better time to launch this RFC would have been when the PM was first thinking about implementing a checklist feature and wanted to understand the impact on the ecosystem, before actually building it.
To avoid the risk of the RFC format feeling like a rubber-stamp checklist item for future projects (at least from the point of view of ecosystem partners), can the RFC requirement be moved to be a gating item early in the feature design/change management process, rather than something that apparently can occur at the tail end of a project?
I believe this issue warrants a more in-depth discussion separately, as the problems mentioned in this topic go far beyond the case of checklists and could significantly impact the future growth of the marketplace.
Upon reviewing the messages, it seems clear that partners have lost considerable trust in Atlassian in recent months due to the ongoing overlap of native features with those available in the marketplace. This situation risks worsening if Atlassian continues to develop competing features while offering only vague promises in response.
What I would expect from Atlassian is an official statement that includes:
A detailed roadmap of upcoming “native features” that may impact the marketplace (we know that the changes won’t stop at checklists and what’s already been released)
How Atlassian plans to address the issue of unfair competition with vendors, including any self-imposed limits as a marketplace controller to maintain a neutral stance and avoid abusing its dominant position or gatekeeping situations
How Atlassian intends to tackle the problem of limited APIs and extension points that prevent vendors from offering quality and competitive products
How Atlassian plans to address the large number of bugs, reports, and technical debt accumulated over the decades on ECOHELP
This would be a much-appreciated first step in restoring some trust and demonstrating Atlassian’s serious commitment to its partners.
Thank you for sharing further information regarding the RFC and the proposed introduction of checklist functionality in Jira. While we appreciate the update and the stated intent to balance customer needs with partner ecosystems, we must express our frustration and disappointment with several aspects of this communication and the broader impact on vendors like ourselves.
First, we believe the 15-minute time slots provided for feedback calls are insufficient, given the importance of this issue. These are critical conversations that require more time to discuss the wide-ranging implications of this decision on our business and product offerings. We would appreciate the opportunity for more extended discussions to ensure all concerns are properly addressed.
Additionally, we are concerned by the absence of any direct communication with us regarding this matter since we raised our concerns with individual Atlassian team members last week. It mirrors previous communication errors and leaves us feeling ignored again, despite our long-standing commitment and contributions to the Atlassian ecosystem. Clear and open communication is vital, and this has again fallen short.
We strongly urge Atlassian to schedule a group call with all checklist vendors to ensure transparency and provide a forum for collective feedback. By having a shared discussion, we can all operate from the same set of facts and provide valuable insights as a group. This is especially important as the potential impact on all vendors is significant, and hearing from multiple perspectives will foster better solutions. We also look forward to the “individual discussions” that you mentioned.
Finally, many of us are re-evaluating our approach to Forge. Recent developments have disrupted our 2025 strategic planning, and we are now uncertain about the level of confidence we can place in Forge as a future investment. Trust is a cornerstone of any partnership, and we need clearer communication and stability to ensure our long-term plans align with Atlassian’s direction.
We look forward to your response and strongly encourage longer, more meaningful discussions that address the real concerns of vendors as we navigate these changes.
Also, we would love to see the answers to questions asked in this forum. Especially the one about “future enhancements” announced in your first message. My current understanding of your second post is that you don’t plan to work on “future enhancements” any longer and you will release only the basic feature of adding items in rich text field (similar to this in Confluence):
Thank you for sharing your concerns and for the time and effort you’ve invested in providing valuable feedback. I’d especially like to acknowledge and thank the partners who joined the recent calls to discuss this matter in greater detail.
To address your key points directly: we will be moving forward with launching only the basic checklist feature in Jira. This decision has been driven by strong customer demand and the need to remain competitive in our space. Our strategy is to provide essential core functionality, allowing vendors the opportunity to build more specialised, advanced features that bring additional value to users.
As we grow Jira to support not only software teams but teams across all disciplines, we are constantly evaluating how best to meet diverse needs. This often requires revisiting concepts and adapting to shifts in the market. While we have no plans to expand this checklist feature today, it’s essential to recognise that our stance may evolve over time as the ecosystem grows and user’s expectations change.
If any shifts do occur, we are committed to proactive communication with our partners. In such instances, we will work closely with you to minimise any impact and ensure we continue to support your valuable role in the ecosystem.
I understand there was considerable sentiment that there is a feeling of an uneven playing field, as well as a lack of clarity around Jira’s longer-term roadmap and concerns over limited API access within Jira. I have shared this feedback with Jira leadership, and while I cannot make any guarantees at this time, we will carefully consider these points. If there are any updates, we will make sure to provide them as soon as possible.
We understand the concerns raised, particularly around the potential impact on business, and we are committed to being as transparent as possible throughout this process. While I cannot make any concrete promises at this time, we are exploring possibilities for co-marketing opportunities and opening up the Action Items feature for extensibility to support vendors.
We value the role our partners play in the Atlassian ecosystem and are actively looking at ways to ensure we can continue to support and grow together. Please continue to share your thoughts with us as we move forward.
I want to express my gratitude once again for your feedback. App partners are a critical and strategic part of our Jira strategy, and the insights you’ve shared have been instrumental in highlighting key opportunities for improvement and growth.
In response to the concerns and opportunities raised, Jira leadership has taken a step forward by creating a product team specifically focused on addressing these challenges and exploring the possibilities you’ve outlined. This team is committed to investigating and acting on the feedback provided.
The newly formed team would love to hear from you and would like you to submit your feedback through this form. Please log or vote for a ticket so that the product team can use that data to make decisions going forward via jira.atlassian.com.
I hope you are able to share your most critical needs with the team openly so that they can figure out how to best work with you to solve our challenges.
Hi @AhmudAuleear, thank you for taking this initiative to ask for feedback. I think it is a great idea.
Could you please also promise to share the survey results (aggregated summary) after it is complete? That would make it more transparent, and would improve the communication between Atlassian and partners.
