Atlassian, stop bullshitting and open source AtlasKit, UI Kit, Forge Runtime, AMPS, Atlas SDK, etc, etc

Dear Atlassian,

It’s 2023 and I can’t believe I’m writing this. You need to start embracing open source.

You have spent over a decade creating a vibrant ecosystem economy, gathering a great bunch of really smart people around you that have been cheering for you and helping you achieve hyper scale growth, either by promoting you with their clients as Solution partners, or by expanding upon your products as Marketplace Partners. Some are even doing both.

As you rightfully concluded when you created the P1 plugin system (and P2, Connect and Forge after that): you can’t cater to every demand on your own. There are too many use cases, to many edge cases, too many niches to attend. Sometimes it better to the 80% yourself and use that 80% to create a system that enables others to go above and beyond to make sure the 20% fits the specific needs of that customer.

Now please apply that same logic to some of the more vital parts of your code base that powers your economy. Start embracing open source.

Take example of other projects out there. For instance, look at Firebase, which you could compare to Forge if you so please. They’ve open sources their SDK, their developer tooling. It’s all there, publicly available on Github. So is React. Or look at your competitors: has released their apps SDK publicly.

There is a ton of knowledge, experience and goodwill in this ecosystem. Start using it. And stop making bullshit excuses that you don’t have the resources to “govern” open source project. Or at least, if you do, than make sure that you have the resources to actually deliver on your promises and make sure your projects are on par and that you’re not breaking industry standards with publicly listed packages on NPM..

You can’t have your cake and eat it. So either you suck it up and invest in the resources to be a proper steward of public code that people depend on, or you make it a collective problem and allow us to take shared responsibility. Either way, stop bullshitting us.

It’s 2023. Start acting like it.


Hi Remie,

Thanks (as always) for your candid feedback!

A small note on my reply: as an ecosystem veteran I know you’re personally pretty across the Atlassian developer landscape and the state of many of these projects, but I’ll attempt to answer your question as holistically as possible for other community members who are perhaps less familiar with the extent of our developer platform.

There are a number of different Atlassian-maintained app development tools, libraries, and frameworks that support the various generations of Atlassian Cloud and Server developer platforms that are in active service. Internally, these tools are owned by a number of different Atlassian teams with varying levels of readiness to support external contributions.

Some tools such as AMPS and the Atlassian Connect frameworks ACE and AC Spring Boot are open source, liberally licensed, and (in theory at least) open for contributions. If you have had trouble contributing to these or any other projects with a or equivalent section in their please let me know and I can chase up the respective team internally.

Other frameworks such as the Forge runtime libraries and toolchain are not currently open source though could be in the future—I’ll come back to this point a bit later in the post. Others such as Atlas Kit currently only have mirrored source code available but are not readily buildable or open for contributions.

We do recognise that Atlas Kit in particular is a pain point for our ecosystem. Internally Atlas Kit has decentralised ownership—a subset of components are owned by our core Design System team, and a number of components are owned by other product and platform teams. For many Atlas Kit components, the primary focus is currently on Atlassian product development, with varying levels of investment and focus on external consumption. This has lead to varying levels of suitability for consuming Atlas Kit components in externally built apps. Atlassian recognises this is a problem and we are tracking this as a priority feedback item on behalf of our developer community that needs investment to improve the productivity of Marketplace Partners and the broader developer ecosystem. We do recognise that Atlas Kit is especially important because it impacts developers across all of our cloud platforms. That said, while I do love the idea of re-open sourcing Atlas Kit and accepting external contributions, it would need some significant investment and a better internal ownership model before it could be run as a successful open source project. We have relayed the idea to the team working on evaluating Atlas Kit’s future for more thorough consideration.

Regarding Forge, there has been significant interest expressed by several ecosystem developers in contributing to the Forge toolchain. The Forge team have taken this on board, and the next generation of several Forge tools are being built with a cleaner separation of concerns and API boundaries as a step towards being able to better support third-party contributions and libraries.

One example is the Forge Function Runtime. The team are experimenting with shifting away from our custom Isolates-based runtime (which has spotty compatibility with popular node libraries) to a vanilla Node.JS runtime. This will allow the usage of any Serverless-compatible Node JS libraries in Forge apps, and also mean that little domain-specific knowledge will be required to contribute to libraries. This is an important pre-requisite to open sourcing the runtime. While I don’t have a firm date I can share at this stage, we are aiming to get this into an EAP release soon.

Another example is Client-Side UI Kit, which is currently in EAP. The Forge team are trialling moving from bespoke UI Kit to React JS in a similar way to how React Native works. This project is in part to introduce complex styling capabilities and interoperability with Custom UI, but also creates a cleaner boundary between Host and App which is again a pre-requisite to supporting external contributions to client-side libraries.

While we do not have a specific roadmap for open sourcing Forge packages, the team are working to shift more Forge-specific logic from internal to externally consumable packages with a view to open sourcing in the future.

I do agree with your observation that there is a huge amount of knowledge, experience, and goodwill in Atlassian’s ecosystem that we could better capitalise on to improve the developer experience and productivity of our toolchain. Atlassian leadership have also indicated that they are keen to better support community contributions across our platform in the future, but do not have a concrete plan that I can share at this stage.

On a final note, we do recognise that at times, individual teams may say Atlassian doesn’t have the resources to do something. What they are often meaning to say is that Atlassian hasn’t prioritised a certain effort at that time for resourcing and that individual or team may not be the right person to speak to broader Atlassian prioritisation or roadmapping on the topic. They can only tell you what the case is at that moment in time. We recognise we need to do a better job at sharing roadmaps with our partners, and are starting to do that through our quarterly Forge webinar and Marketplace webinar. We hope to continue to grow and evolve these as well as introduce more scalable ways to share visibility on what we’re doing and not doing in a given timeframe to discuss it more constructively rather than leaving you or others feeling like you’re in the dark.


Tim Pettersen

Head of Developer Experience


Remie is certainly one of the more vocal developers about those issues. Can’t thank him enough for expressing this. But there are countless developers and vendors who suffer from this every day. We all have a problem with it.

Some veterans know how to work around all of those quirks. It’s actually a huge competitive advantage. If you’re a newcomer, good luck.

Data Center is in a pretty sad spot. The state of the art is working with 2015 technology (Java 8, jQuery, ancient server stack, etc.). Sometimes you can use some modern tools in some areas, but only if you’re lucky and willing (and able!) to invest a ton of frustrating time into figuring out your path through this minefield.

Cloud is sometimes better, but sometimes even worse. It’s still not clear if the future is Connect, Forge, or both (and which one you should use when). While you can figure something out by reading the source or even decompiling some code in DC, a lot of the time that’s not an option in Cloud. It’s countless hours of guesswork and reverse-engineering a blackbox. Even if you get it to work today, it may break tomorrow.

A lot of these tools (DC and Cloud) feel like half-baked, sometimes abandoned products. Like some team somewhere in a massive organization had an idea, made some progress, got something released… And then lost interest, got disbanded or pulled to other work.

We know it happens, and honestly we don’t care.

Remie is absolutely correct that all these tools need serious investment. They have to be first class citizens. They have to be up to date. They have to be flexible. They have to take into account feedback from us, developers, who actually use them every day.


We do recognise that Atlas Kit in particular is a pain point for our ecosystem. Internally Atlas Kit has decentralised ownership—a subset of components are owned by our core Design System team, and a number of components are owned by other product and platform teams.

Yes, Atlaskit is one of the biggest pain points and you have your answer already - just split the damn thing to match the ownership. As a vendor I don’t mind dropping some parts of it (assuming it’s not the majority) to have a better experience and a true open-source project.

Also, @remie is the last man standing here still trying to convince you to up your game. I don’t see many replies here and I guess plenty of vendors already checked out and don’t believe in major improvements.


Has there been any progress on this? I do not think the excuse that it’s ‘difficult’ to open-source atlaskit holds a lot of water.

The obvious method of doing this is to keep going as you are, and make the development repository public just like you’ve currently made the mirror public.

We’d be better off just mirroring the mirror repo to Github and automatically patching it every day with whatever is updated on the mirror repository (yes, I realize the irony of using Github for that).

You are absolutely right. No reliable documentation, no support for novice users and when new updates come along, they just bring more chaos. I am already annoyed by this…