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 CONTRIBUTING.md or equivalent section in their README.md 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.
cheers,
Tim Pettersen
Head of Developer Experience