What is the relationship between Atlassian and the Marketplace vendors?

Question

Hello, all.

I am curious, what is the relationship between Atlassian and the Marketplace vendors?

For example, It seems to me there are many obvious, and missing, features of native Jira to make it viable for enterprise agile development.  Two such cases are:

* Better access/reporting to issue log information via filters, and
* Configurable board reporting that matches the practices used (Scrum or Kanban).

These have been available in the Markeplace for years and yet Jira has not enhanced the native product to include these.  Please review the suggestion/issue backlog for other examples...and check the issue create dates to see how long ago they were suggested.

Once such a feature becomes available in the Marketplace, is Atlassian disincentivized through its agreements to not add the feature to native Jira?

Thanks in advance for any relevant replies.

Daniel Eads · Answer

The following comments are based on my experience as an Atlassian customer for many years before joining the Atlassian team. They don't necessarily reflect the official viewpoint or strategy of Atlassian.

One thing that's very apparent in software is that there's no "one size fits all" approach. What seems like an obvious missing feature to you is something that another administrator with the same license size as yours might say is needless. The diversity of requirements between companies and teams is actually what makes the marketplace so robust. "The most critical features for the most users" wind up in the product. Some things that some people might absolutely require to use Jira are provided by the marketplace. It's the product managers at Atlassian who conduct interviews, do research, and ultimately make the call on what makes a native feature.

In my role as an Atlassian administrator, the organization I worked for didn't do time tracking in Jira. I heard from people in other companies that they thought time tracking and reports were a native feature, because they'd always had it and everyone in their company logged time. Indeed, Tempo has consistently been in the top 3 selling apps on the Marketplace for, well, as long as I can remember. One might make the case that it should be a core part of Jira, but it wouldn't have been useful to the organization I admin'd for.

Nic mentions not de-incentivizing vendors. I'd say this isn't always the case - for example I recall a couple plugins providing canned responses before the actual product introduction of canned responses in Jira Service Desk. The marketplace options still have extended features, but "snippets" are a core part of service desks, so at least the minimum snippet functionality was added to the native product.

On the acquisition side, sometimes there are competing add-ons with similar featuresets. The acquisition of Good Software last year brought "Analytics for Confluence" under the native Atlassian umbrella. Viewtracker is still available on the marketplace, despite those two fulfilling nearly the same role.

I'd like to examine some of your statements on native-adding the features you suggested:

Atlassian could add the missing features to make the product more desirable, cost effective, and stable for customers

* more desirable - this may be in the eye of the beholder. I found as a customer that the robust marketplace offerings met the needs of my organization as they came up. The availability of many apps was actually a selling point for us vs. some other options which weren't as extendable.
* cost effective - the cost of adding many features currently offered by the marketplace into the core product would increase the costs to develop and maintain the core offering, making the core offering more expensive. I won't go into a diatribe on this, other than making the comparison that a standard car "with all the options" still comes out slightly less expensive than the same company's luxury-badged option.
* stable - with more features come less maintainability. Things like platform upgrades take longer to work through and test when there's more features to be tested. And in some cases, those features become "good enough" and don't receive any additional development resources. In the case of vendors, they don't make any money unless the add-on works well and people keep subscribing to it. I'd say this is significant incentive to keep the app working well and adding new features when it becomes apparent that users want them. It's surely possible to get an app from a less experienced vendor and have bugs sneak into releases, but that's more on the administrator to weigh which vendor they want to go with for a particular app. Careful selection for stability vs feature speed can be made for even apps on the marketplace.

Whew! I hope that adds some thoughts to the process. Again, these comments are based on my individual opinions as a former admin and not necessarily representative of Atlassian's official viewpoints.

Cheers,
Daniel

Nic Brough -Adaptavist- · Answer

Atlassian also lean heavily on their partners to support and expand the user base.

Incorporating features from vendors into the product damages the vendor, dieincetivising them from supporting and promoting the products, so Atlassian mostly avoid building their own versions of vendor tools.  When there is a strong need to build something that a vendor has done, they acquire instead of compete.  Jira Service Desk has some IPR from a vendor, Portfolio, Align and Software were acquired, as were smaller things like Good Software.

Bill Sheboy · Answer

Hi @Paweł Albecki

Thanks for your thoughts.  To answer your question, Atlassian could add the missing features to make the product more desirable, cost effective, and stable for customers.

Add-ons are...well...add-ons; they add cost to customers monthly, and because they are not part of the core design or solution, they can be both unstable and alter the designers' consistency of approach.

Best regards,
Bill