Disclaimer: this post is not intended to bash Atlassian, the Forge team or anyone else for that matter. The purpose is to start an honest and open conversation about the future of Forge.
This week, Atlassian published a blog post to celebrate the one year anniversary of Forge. The post included some milestones that have been achieved. Obviously, these numbers drew the attention of the Atlassian Marketplace community as they are an indication of Forge adoption.
At first, the numbers look pretty decent. However, this is a very thin veil to conceal a more distressing reality.
The number of apps created seems impressive, until you look at a different number shown in one of the talks at Atlassian Dev Day ‘22 (BONUS TALK - Forge on Forge: How the Forge team builds Forge apps at Atlassian)
Out of the 5600 apps created, 2844 were created by Atlassian. That is a little over 50%. In addition, out of all these apps created by Atlassian the
[..] conversion from forge create app to anything useful is ~ 6% even in house. That leaves us with 2756 apps that were created by external developers.
Another number that is interesting to Atlassian Marketplace Partners is the number of apps available on the Atlassian Marketplace. The blog post mentions 200+ apps available on the Atlassian Marketplace. Let’s dig a little deeper into this number.
The total number of Forge apps published to the Atlassian Marketplace on July 12 was 239. Out of those 239, there are 6 apps that are created by Atlassian. So that leaves us with 233 apps created by Atlassian Marketplace Partners. Out of 2756 Forge apps created by external developers, only 233 are published on the Atlassian Marketplace (~8.5%).
117 apps are free apps, 116 are paid
The 116 paid apps have been installed into 10,081 instances, reaching 8,613,148 users*
Out of 116 paid apps, 94 have less than 100 installs
Forge has been in development by Atlassian since early ‘19, with the first announcement at AtlasCamp‘19 in Vienna. Atlassian has been pouring resources into this framework ever since, and Atlassian Marketplace Partners have been as well. It is not a stretch to say that diverting those resources has resulted in less investments in improvements of both Atlassian products and Atlassian Marketplace Partner apps.
With roughly 3 years of development and being GA for one of those, looking at the actual adoption of the Forge platform is reason for concern. Especially given the amount of goodwill from the Atlassian Marketplace Partner community. Most Atlassian Marketplace Partners are very eager to work with Forge, spending lots of developer time on it, giving feedback, participating in Codegeist, joining calls with Atlassian, contributing to Dev Day ‘22 and publishing the apps to the Atlassian Marketplace.
So here is my take on what may have contributed to the current state in terms of adoption, what is left of the initial goals and why doubling down on Forge is not the most obvious way forward.
How did we get at the current state
This is not an exhaustive list, and there are many more reasons why adoption may have been slow, but I think in terms of discussions on CDAC these are a few topics that have been popping up most frequently.
Forge UI versus Custom UI
Initially, Forge shipped with Forge UI support only. This is a limited set of server-side rendered front-end components using a similar syntax as React/JSX. Although it allows for rapid prototyping, Atlassian Marketplace Partners soon discovered that, apart from the required investment into a different UI library, Forge UI also could not meet their standards for creating appealing user interfaces.
It took a while until Custom UI became available in November ‘20 (⚡️ Introducing Custom UI: Static HTML/CSS/JS frontends on Forge) and even longer for it to support more advanced features like routing, code reusability, etc.
Forge Storage API
Having the ability to store data within the Atlassian infrastructure has been a popular request ever since the implementation of GDPR. This is an important asset for Forge, but unfortunately also proved to be a huge blocker for most app developers. The initial size limit of 32kb, API limitations with regards to querying data, overall performance and quotas meant that either a significant engineering investment was required or the app would require alternative storage outside of Atlassian.
Lack of parity with Connect
Up until recently, the number of integration points for Forge apps have been very limited. Important products like JSM were out of scope even at GA, and popular integration points that many developers are using in Connect were unsupported. Getting Connect parity in terms of integration points has been coming in waves, with priority choices that were not always clear or relatable to the Atlassian Marketplace Partner community. A lot of the default building blocks that are part of almost all Connect apps just weren’t available to Forge for a long time.
Up until this year, most of the quota’s for Forge did not make sense with regard to the needs of large and complex apps. A execution timeout of 10s for functions, a max package size of 256MB and 32KB of storage per entity just simply isn’t enough. It’s fine for Hello World playground type of projects, but the amount of engineering required to support complex apps within these boundaries made it unattractive to invest in Forge when developing any serious app for the Atlassian Marketplace.
Overall developer experience
In short, the developer experience has not been great. The lack of multi-ownership, an unstable CLI with random errors, the granular scopes debacle, lack of communications of changes (like the fact that Forge Storage API file size limitations were increased), the lack of ability to migrate Connect apps to Forge on the Atlassian Marketplace, slow performance and priorities that are alienating to the Atlassian Marketplace Partner community have resulted in a lot of frustration and friction, preventing mass adoption.
What is left of the initial goals
When Forge was introduced, there were a couple of important pillars that have been repeated over and over again as a justification for the platform and as a reason why Connect will eventually be deprecated. Now that we are 3 years in, let’s look at what is left of these goals.
Here is how it was announced:
The Forge platform is a reimagining of cloud app development for our ecosystem, composed of three advanced components:
- A serverless Functions-as-a-Service (FaaS) hosted platform with Atlassian-operated compute and storage for app developers
- A flexible declarative UI language (Forge UI) that enables developers to build interactive user experiences across web and devices with just a few lines of code
- A state-of-the-art DevOps toolchain, powered by the intuitive Forge Command Line Interface (CLI).
Forge helps solve for a whole host of cloud considerations, including:
- Trust: As personal information goes digital, privacy, transparency, and security are more important than ever before. With Forge UI, developers and app consumers benefit from built-in, best-in-class security for apps, by default. Plus, thanks to Atlaskit, when Atlassian makes an update, your apps won’t break.
- Running anywhere: Atlassian customers want experiences that are consistent across their products and apps, and across their devices and web. Forge’s UI enables users to build once for both web and mobile.
- Moving up the stack: In general, developers aren’t concerned with where their code is running – they simply want to spend less time on implementation details of the code, and more time on providing customer value. Forge’s serverless FaaS model enables developers to write single functions rather than building entire web applications.
It is often great to look back at what was initially conceived and how it panned out. Just looking at this quote you can already see that the focus started to shift quickly after Forge was introduced. For instance, one of the things that became obvious was that Atlassian-operated compute and storage was not going to work out because Atlassian would not be providing every type of solution that app developers might need. The same applies to Forge UI. Support for mobile is still in the works and as an Atlassian Marketplace Partner it is unclear how this will work and whether it will fulfill the promise of “build once for both web and mobile”. The DX of both the CLI and overall stack shows that at this point, Forge is actually a greater investment for Atlassian Marketplace Partners. One year after GA the platform is not delivering on any these promises.
But more importantly, let’s do a deep dive into the biggest selling point of Forge: trust / security. Here are the main argument for using Forge over Connect with regard to trust / security:
It runs on Atlassian Infrastructure
As previously mentioned, this is not entirely true. Atlassian will not be able to, and does not have to, provide all the services required for creating complex apps. This means that a lot of Forge apps will continue to use 3rd party services and transfer data outside of Atlassian Infrastructure for processing.
Due to the limitations of Forge, a lot of Atlassian Marketplace Partners will require external storage (database), compute (for specific use cases) and even means to contact the Atlassian API externally (which will be made available as part of the Connect on Forge plan).
This also means that a lot of Atlassian Marketplace Partners will still need to be considered data processors separate from Atlassian, and security audits will still be required for most customers.
Forge users are more informed about data egress & permissions
Yes, this is true. Forge apps are required to list all external services to which data will be shared and when granular scopes are implemented this will allow for more detailed control over permissions. But that is not specific to Forge. This could have been implemented for Connect as well.
Forge has out-of-the-box support for data residency
Yes, but… Atlassian Marketplace Partners are more than happy to implement support for data residency in Connect except are currently blocked by Atlassian due to stalled implementation in Connect.
Forge has better authentication / The current JWT / iframe solution of Connect is outdated
There is no reason why Connect cannot switch to industry standards for authentication, like OAuth. Using iframes is not per definition a security problem, a lot of other SaaS products that support 3rd party integrations use iframes. This is the industry standard for in-app extensions. Just like having a bridge between the iframe and host product. If security concerns for the current Connect implementation are the main driver, creating the Forge infrastructure was and is not the only option available.
Why doubling down on Forge is not the most obvious way forward
With Atlassian doubling down on Forge, there also comes a real incentive to artificially beef up the numbers of apps. This is a path that Atlassian is already taking with the Connect on Forge initiative, which is meant to create the ability for Atlassian Marketplace Partners to migrate existing Connect apps to Forge.
It is becoming increasingly clear that the goal of moving Atlassian Marketplace Partners to Forge comes at a great cost with regard to the initial plans of Forge.
By accepting the fact that complex apps will need data egress, compute, storage and API access outside of Forge, the goal to address the security concerns that Forge was meant to resolve is watered down.
Another way that Atlassian is doubling down on Forge is by deprecating Connect features and making them Forge only, by not adding support for Connect for new products (like Atlas and Compass) and by only making new integrations to existing products available on Forge. Unfortunately, due to all the previously mentioned frictions, this currently only means that either existing apps lose functionality, cannot make use of new functionality and that the new functionality will probably not be used due to lack of Forge adoption. There is no audience for what Atlassian is building.
While there are many great use cases for Forge, and there is definitely a place for Forge within the Atlassian Ecosystem, doubling down on Forge as a replacement for Connect may not be the best decision.
- It erodes the initial goals of Forge
- It creates friction & frustration within the Atlassian Marketplace Partner community
- It distracts developers from delivering value to customers
Instead of spending a lot of time and effort in trying to increase Forge adoption by artificially pretending that Connect apps are now “on Forge”, Atlassian can also decide to spent that engineering time on improving security of Connect and leave that platform available to Atlassian Marketplace Partners for the more advanced features.
I really hope that now that we have celebrated the one year anniversary of Forge and are preparing to wind down during the well deserved holiday season, there is also room to reflect on the decision that have been made, the impact that they have had on both Atlassian and the Atlassian Marketplace Partner community and to reconsider the path forward.
*) the total number of installs & users is skewed by the fact that some forge apps also have Server/DC deployments and the distribution numbers are combined for all platforms