Why is Atlassian phasing out Plugins Studio rather than transitioning it to OnDemand?

[Steffen Opel]

As still suggested in the outdated documentation for Packaging and Releasing your Plugin, I had applied for a respective Plugins Studio project for the Bamboo AWS Plugin in November 2011. I have been referred to Bitbucket as a workaround already back then, albeit only because Atlassian is working right now to transition our Plugins Studio instance to OnDemand.

Now things apparently changed, insofar a more recent Atlassian support quote states Atlassian is actually phasing out that service, in favor of Bitbucket. This is meanwhile reflected on Plugins Studio as well in a banner that reads:

studio.plugins.atlassian.com is no longer accepting new projects. For free code, issue and wiki hosting, we offer BitBucket. For officially supported hosted Atlassian offerings, please see OnDemand.

Frankly, both as a customer as well as a plugin developer, this change in strategy leaves me severely puzzled:

• Bitbucket is excellent for what it offers of course, and I happily use it wherever applicable. I can also see the current overlap in functionality complicating this a bit from a business development perspective for example.
• However, I'm using (and promoting) the much more powerful Atlassian tools suite for a reason, and I expect being able to use the very same tools I'm developing plugins for during their development as well of course (if I so chose).
• One major promise of OnDemand has been the simultaneous release of hosted and on-premise versions - what could be a better way to increase awareness of changes in Atlassian tools for plugin developers than letting them use those every day? (I'm aware that most plugins won't be available in OnDemand, but still ...)
• Atlassian regularly stresses the importance of dogfooding in general and public dogfooding in particular - why would you wanna let go the chance to apply this practice regarding a particularly motivated and affiliated group of users?

Are there any insights into this decision available? Thanks much!

[BenB]

Many thanks to Joseph for his thorough and correct answer, most of which I was about to write myself in a more poorly-phrased manner.

I will add only a few qualifying statements:

• First, studio.plugins.atlassian.com is not going away anytime soon -- not next week, not next month, possibly not even next year. Our discussions with project owners has shown us that much existing work has gone into a number of projects hosted there, and we are not going to force anyone off the server without a migration plan.
• We have stopped accepting new projects because, as Joseph said, server load is high enough that we cannot guarantee an acceptable level of service for existing projects if more are created. It is not meant to come across as Atlassian disavowing interest in hosting our ecosystem's development. It is meant to protect the user experience of the projects already there.
• We realize that BitBucket is not a full-fledged hosted software development solution in the same way that OnDemand is. A large number of project owners have told us that BitBucket cannot replace their hosted projects, and that information is spurring us to find ways to offer OnDemand to ecosystem developers on the most liberal terms possible.

We will be announcing more details as we settle on them in the next few weeks. Of course, we are always available at developer-relations@atlassian.com if you have questions about this.

Thanks!

[Joe Clark]

Hey Steffen,

I guess there are two main questions here:

1) Why are we phasing out Atlassian Plugins Studio?

Lots of reasons, really.

• Many (but not all) of the projects currently on studio.plugins.atlassian.com are not using any of the powerful features available in JIRA Studio (Bamboo, Crucible reviews, Wiki). Most projects are just using the subversion repository and the JIRA project.

• The performance of the instance has degraded over time as the number of projects on the Studio server has increased. Unfortunately we are reaching the limit (or have already reached) the limit of projects on a single Studio instance where performance can remain suitable.

• When the plugin studio instance was first launched, there were no other good options for Atlassian to host your plugin code for you. The rise of github & bitbucket has really changed the source-code hosting market.
  
  
• Plugin studio is a custom install of JIRA Studio and does not sit in the same infrastructure bracket as other Studio instances. Over time these customisations have made ongoing support of the system difficult.
  
  
• Time spent maintaining a JIRA Studio instance could instead be spent doing other awesome things for plugin develpoers.

2) Why are we suggesting Bitbucket as a replacement for projects already on Plugins Studio?

To clarify, we think that for most projects, Bitbucket will be a suitable replacement. The majority of projects on Plugins Studio just needed a place to dump source code.

For some projects, the advanced features of the Atlassian suite are being used to great effect, and Bitbucket does not provide a full replacement for all the functionality of JIRA Studio. In this case, we are still working out a plan to possibly offer OnDemand instances to these plugins. The instances may be provided free of charge by Atlassian in some cases, or may be offered at a reduced cost; we haven't worked out the details yet.

I'm sure the Developer Relations team will do their best to keep you informed!

[JamieA]

A couple of questions about this:

Are you hitting performance limits due to number of projects, or number of issues? If projects that's a bit alarming, as we're allowing self-service project creation across all the tools here. I didn't realise # projects was a limiting factor.

I already use BB so not remotely bothered about dropping svn hosting, or fisheye/crucible. BB has adequate issue tracking so jira can go too. I would be sorry/annoyed if confluence was dropped as porting all the docs, and all the comments to another wiki would be extremely painful. Not to mention the amount of links to Confluence embedded in questions on this site etc.

[Bob Swift OSS (Bob Swift Atlassian Apps)]

JIRA is just as important for the same reasons as Confluence - lots of links and documentation. No problem with dropping svn and fisheye.

[JamieA]

Yeah, agreed about the jira issues. However if someone else moved them all to BB issues without losing anything, I wouldn't be too bothered. I guess that's also true of confluence. But I doubt that that will be easy.

[BenB]

The performance problems are inherent to the older architecture of JIRA Studio and were a primary motivator for the OnDemand redesign. A project on studio.plugins.atlassian.com includes a JIRA project, a Confluence space, and a FishEye and Crucible repository. These components take up resources even if the projects aren't using them, so the machine is currently running ~700 FishEye/Crucible instances alongside a JIRA with the same number of projects and a Confluence with the same number of spaces. We bought some time by turning off FishEye for inactive projects, but at the current rate of project growth it wasn't going to be long before the entire thing ground to a halt.

As far as BitBucket migration goes, we're figuring out how to make it work for those projects that are interested. However, I'll emphasize again that we are not kicking anybody off of studio.plugins.atlassian.com in the near future. Project history is important, not least because of Google indexing.

[jnolen]

FYI Brendan, both of your suggestions are on the table. We're just trying to figoure out the least painful way to get there.

[Brendan Patterson]

Hi,

OK this is a kind of a big deal for plugin developers and the ecosystem. An evolution makes sense but I'd like to offer a couple of clarifying thoughts as well as brainstorm type suggestions.

First off S.P.A.C. has been awesome. It frees plugin developers from having to set up their own server for docs, issue tracking, version control and so on. This has been a boon to the ecosystem removing several barriers for plugin devs.

As for this comment @Joseph Clark:

To clarify, we think that for most projects, Bitbucket will be a suitable replacement. The majority of projects on Plugins Studio just needed a place to dump source code.

I appreciate all the helpful info and insight into what Atlassian is thinking. But "just needed a place to dump source code" - in my opinion for any marginally useful plugin nothing could be farther from the truth here. I would argue without good documentation and issue tracking there is no such thing as 'a useful plugin'.

I am loving BitBucket big time for source code. Subersion is now a relic.

However I'm fairly confident no teams inside Atlassian are using the BitBucket wiki or issue tracking (except possibly the BitBucket team) for obvious reasons.

Quite honestly we're spoiled on Atlassian tools. We love them and don't want to use anything more marginal.

When you look at plugins/extensions from people like Bob Swift and Andy Brook (just to name a couple) you are talking hundreds (thousands?) of hours spent enhancing in the products in incredibly valuable ways used by probably millions of your users directly or indirectly. I think it's key to consider how to make things as easy as possible for devs like that - the value Atlassian derives is almost incalculable.

Suggestions:

• let plugin-devs migrate their own stuff to OnDemand. this saves Atlassian work and will reduce load on S.P.A.C
• if you need some bar for a plugin to be "OnDemand worthy" create that bar and then offer it

Out of chars for this 'comment' @a.a.c :)