<aside> 🌍 This page is public. Read about our take on public when possible, private when necessary.
<aside> 👐 Maintained ****by @Sven Efftinge and @Johannes Landgraf . Contribute to this page using our contributor flow.
This page introduces Gitpod's purpose (why), vision (what), and strategy (how we get there).
Remove all friction from the developer experience to be always ready-to-code and make software engineering more collaborative, joyful, and secure.
Product Vision: By 2024 working with ephemeral cloud-based developer environments will be the standard, just like CI/CD or versioning source code is in 2022.
Developers are automating the world, yet they waste a lot of precious energy manually setting up and maintaining developer environments. Millions of developers are slowed down on a daily basis with tedious tasks to get into a productive state while also facing annoying "works-on-my-machine" problems.
Professional software engineers easily spin-up fresh developer environments for any task. Those ephemeral environments are fully prepared and initialized empowering developers to immediately start coding, debugging, and testing their code. Only then developers are always ready-to-code.
Dev environments as code imply they are reproducible at any time, any state, and any context of their projects.
Dev environments blend into existing workflows and streamline the developer experience. Developers use the tools of the trade (i.e. anything popular in the developer world) with Gitpod.
As buying power shifts to individual developers to be successful we have to win the hearts and minds of developers. We are embracing a developer-first, bottom-up model focusing on the needs and wants of developers. Developers are our primary users and making them happy and seeing the value in Gitpod will be key to convincing the buyers (managers) as well.
To make Gitpod as easily accessible as possible for everyone writing code, we have developed Gitpod in the open and offer a generous free SaaS offering (why we went open source from a business point of view).
Breaking down what is important in our go-to-developer model, there are the following areas, we will continuously track and benchmark ourselves against:
We aim to be the best-of-breed tool when it comes to developer environment automation. This means integrating very well with existing tools and setups. We aim for an orthogonal product design, one that allows developers to reuse existing tech and knowledge while using Gitpod. Gitpod should feel blazingly fast and clean to use.
Gitpod shall have a style and feel that developers deeply love and appreciate. This is about values, attitude, and design. We aim for a simple orthogonal product design, that builds upon solutions developed by the wider community and avoids hairy, complex design decisions. Next to our brand, visual design, and in-product experience, this focus also applies to documentation and building out our community.