JetBrains Space Extensibility Manifesto
From day one, Space has been designed as a platform, both in terms of product extensibility and business opportunities. We realize that it’s impossible to provide all the professional tools required to support all the various team processes and workflows in a single product, especially given the enormous variety of domains and verticals. That’s why we’re nurturing a strong partner ecosystem for Space rather than developing all the functionality ourselves. This manifesto should shed some light on what can be extended in Space, as well as how it can be extended.
Building an extensible platform is an essential part of our vision for Space. JetBrains is committed to providing a top-notch core platform with various ways to customize and expand Space in many directions. We call them extensibility rails, and they run in parallel with the different functional areas of the product. We are much more interested in integrations and applications that extend Space to work with external tools and data, rather than in replacing one of the Space modules with an external tool. We truly believe that the power is in the integration and in building on top of the base functionality to benefit both tools.
So far, we have identified the following extensibility rails, but more will be added as the product develops:
General-purpose integrations can be used for a wide range of use cases. Those include getting data from Space to pass it to an external system (via HTTP API, Client SDK, or export to CSV/JSON), to push data to Space from an external system, or to modify data in Space based on external events (via HTTP API, Client SDK, or import from CSV/JSON). In general, all Space UI actions will be available via the API/SDK. Every Space module can be extended.
Space must support the bulk importing of data for major product modules, such as the team directory (profiles, teams, locations, roles, memberships), issues, documents, and so on. There are no plans to support two-way synchronization out of the box, as we will only implement a one-time import on our side.
To keep data in Space, custom fields are introduced across relevant entities (e.g. for team directory profiles or issues), and they can be used to store information from external systems and applications. In the future, we have plans for custom object storage, so custom data can be stored in Space and attributed to various entities.
Both sides can facilitate communication between Space and external solutions. Space can react to a call from the external integration (HTTP API, Client SDK, Incoming Webhooks), or the external integration can respond to some event happening in Space (HTTP API with ETag pull, Webhooks push, /commands in chats, extensible menu call, external widgets on the dashboard, interactive buttons in chats, etc.)
Some good examples: two-way synchronization between Space issues and Jira issues with custom fields; migration of chat history from Slack; export of vacation data for external HR or accounting systems; triggering the build in external CI/CD (e.g. CircleCI) when a code review is closed in Space.
Space provides an integrated and extensible way to control user information (profiles), permission groups, and access. It is possible to synchronize Users and Groups through teams, projects, and roles. A user can generally define the team once and reuse it across all the areas in Space, including external applications connected to the Space instance. Access and membership can be requested and granted via Space, too. To facilitate the secure sharing of secrets, Space implements a shared secrets storage that relies on the permissions and access granted to the user. For even more security, Space provides an audit, alerting, and monitoring for permissions.
Space can also be used as an Authorization Server (OAuth2-based). To provide access to Space for applications, integrations, and external services, Space uses OAuth 2.0, too, so applications should be registered as OAuth 2.0 Clients.
Some good examples: control access to external application artifacts (documents, issues) based on Space team membership; synchronization of custom permissions and groups between Space and GitLab.
Notifications and interactive messaging
Chats in Space is a fundamental concept and a core part of the collaboration workflow. It lets users receive personalized notifications, reply and react from chats, perform code reviews, track issues, share articles, and benefit from the smart grouping of channels and feeds.
Space implements a flexible information and notifications hub, optimized for team collaboration, and we expect external applications to contribute to that in terms of content, notification processing, and interactions. In this way, a user can route many external reporters (for example, external monitoring systems) right into Space and react in-place. Many different workflow automations are possible here, and a lot of application interactions happen in chats.
Some good examples: route alerts from NewRelic/OpsGenie to Space Chats, with special interactive buttons to pass actions back to NewRelic/OpsGenie; send a request for daily standup updates to the team and collect responses.
Space provides calendars and calendar data aggregated for team use. Users can consult the team calendar for an overall picture of teammates’ availability and see their collective planned vacations, business trips, and other absences. On a personal level, the calendars help with scheduling meetings and resolving scheduling conflicts.
Space delivers tight integration with G Suite Calendar (AKA Google Calendar AKA Google Workspace Calendar) and Microsoft Office 365 Calendar (AKA Outlook Calendar). For other calendar providers, Space exposes a CalDav API and import/export functionality for calendar data (for both personal and team calendars).
Some good examples: connect Calendly to Space meetings to allow scheduling via Space; connect Apple/iCloud calendar to Space calendar.
External artifacts & document types
Space implements a knowledge base and project documentation out of the box, and it can be extended with additional document types and artifacts from external systems. The external content will be able to be organized, browsed, and edited in Space.
A simple version of this extension direction includes just unfurling document content and providing authenticated access to an external system (also covered under “External entities” below). Still, it should be later extended with a rich in-place editor for external document types and artifacts right in Space, as well as a way to browse them in Space.
Some good examples: provide support for various tools artifacts, such as Figma, LucidChart, Draw.io, and Miro.
External build tools can be integrated to complement built-in Space automations (CI/CD). Build results from external build tools can be shown in the project graph in Space, and the same external status can be used for merge requests in Space git repositories. Notifications about build failures or successes can be routed to Space chats and organized. Additionally, some advanced workflows can be built around extended information about inspections.
Some good examples: pass build results from GitLab/GitHub to Space.
Space will include built-in support for external calls as part of Space meetings. They will be integrated across all relevant Space modules. For example, it will be easy to schedule a meeting with a call from the chat window, video call info can be attributed to the meeting, recordings can be accessed from the meeting information, etc.
In addition to the built-in calls, Space will also integrate with two leading video conferencing software vendors: Google Meet (as a part of the G Suite/Google Workspace integration) and Zoom. Video call extensibility will be standardized so that our partners can provide support for other video conferencing software.
Some good examples: provide support for other video conferencing systems, such as Cisco Webex, GoToMeeting, Skype, and Line.
Space provides issues/planning functionality but doesn’t provide an open support desk, though it’s possible to create an external ticketing system or request processing system. The Space issue tracker can be used as a backend for issues created from the external user feedback processing system.
Some good examples: create an external form outside of Space that can gather feedback and pass it to the issue; create an equipment booking system based on Space issues that is available outside of Space.
There are a lot of external entities and artifacts that can be mentioned/referenced in Space (for example, as a link or mention in Chats or in a Document).
Space still needs to provide unfurls, show document/artifact/image previews, provide links to external issues/builds/documents where it is appropriate in the UI (e.g. a link to an issue from a commit message). Quick actions could also be provided (e.g. close issue or change status).
Some good examples: full support for Google Docs, Dropbox, Google Drive.
Domain-specific workflows templates
As there are a lot of industries, domains, and standard processes where Space can be helpful, some predefined workflow templates to cover specific use cases can be distributed via Applications. These applications don’t necessarily integrate with anything external but rather configure Space in a particular way simply by adjusting Space entities, such as custom fields, permissions, webhooks, etc.
Some good examples: prepare a workflow template that would make Space usable in retail; prepare a workflow template that would make Space usable in the mining industry.
No two companies are exactly the same, and each needs the right tools to make Space match its processes. That is why there are several layers of Space extensibility, which all require different levels of technical proficiency. A lot of automation can be done in-product with almost no technical difficulty, and then it can all be expanded with coded applications on top of Space. Right now, Space provides the following extensibility tools (many of them are already available in the Space Cloud, some are coming very soon):
- HTTP API.
- Space Client SDK for Kotlin and .NET.
- Custom fields (in team directory profiles, issues).
- Applications (limited support).
- Automation jobs.
- Interactive bots.
- Slash commands.
- Zapier integration.
- Space as an authorization server (OAuth 2.0).
And here are some additional extensibility tools we are working on:
- Full support for Marketplace and private applications.
- Even broader HTTP API.
- Extensive support of webhooks for all Space events.
- Reverse webhooks (also known as “Incoming webhooks”).
- More interactive messages workflows, including forms.
- Extensible menus and UI customization, support for iFrames.
- Local chatbots and workflows (arbitrary Kotlin scripts that Space runs using its Automation infrastructure).
- Custom object storage to keep additional information for applications.
We understand that some of the integrations with external systems will still have to be built by JetBrains. There are competitor tools that are dominant in some markets, and it would be harmful for Space not to have integrations with them. However, JetBrains would like to avoid building these integrations ourselves, and we would be glad to have partners covering as much as they can. So far, our stance is as follows:
JetBrains is mainly dedicating its efforts to the core of the product, building an out-of-the-box experience for all the modules, and providing an extensible platform so that partners can build additional extensions and integrations for various verticals and domains.
The platform is meant to be open, and JetBrains is not going to limit any API / extension points, which means that partners and customers are free to provide any integrations. Both free and paid applications will be distributed via JetBrains Marketplace.
JetBrains will be providing one-time migrations for the most popular/leading competitors’ tools and will release them as open source code on GitHub as model scripts that can be used by partners and customers to expand and build upon. However, JetBrains won’t be actively working to provide a full self-service wizard experience for custom migrations, which gives partners quite a big field to work in. Partners can build upon JetBrains-built migration mechanisms, which are now being developed, or they can design their own. No two-way-synchronization applications are planned on the JetBrains side.
JetBrains will be providing tight integration with at most a few major competitors for each module where it makes sense. For example, we will integrate with Google Calendar and Microsoft Outlook for the calendar/meetings module, and we will provide a way to extend it via custom calendar providers. But we won’t pursue every calendar/meetings provider out there. Other calendar vendors can be integrated by partners.
JetBrains doesn’t plan to integrate fully with external chats (such as Slack or Microsoft Teams) – that also can be handled by partners.
At the beginning of this journey, JetBrains is mostly focusing on the best possible experience for developer-oriented teams/organizations, with plans to later scale it to other creative teams/organizations, and from there going vertical by vertical. There is huge potential for partners to build a vertical-specific experience on top of Space via Applications.
JetBrains will be building some integrations with existing JetBrains team tools (TeamCity, YouTrack, Upsource), but it seems there’s room for partners to build even more advanced integrations here.
We hope that this manifesto helps you understand our stance on the extensibility and our plans around it. Should you have any questions, feel free to reach out to us in the comments to this blog post or via firstname.lastname@example.org. If you are interested in partnering with JetBrains Space and building on top of it, please have a look at the JetBrains Space Partnership Programs.
The JetBrains Space team