As we triage issues, evaluate pull requests, and discuss new features, the Kactus team is making decisions based on our vision for the Kactus product. The purpose of this document is to transparently share our collective view of what Kactus is and who we’re optimizing for when making decisions. Our goal is to be able to point back to this document to ensure there are fewer surprises and that we’re consistent in our product decisions. This will likely evolve over time as we continue to learn more about our users and the problem space.
Our goal with Kactus is to remove frustration, awkward interactions, and “oh no” moments for as many people as possible. We aim to make common workflows* (defined at the end of this document) so simple that beginner and experienced developers alike are productive in working with Git and GitHub. Git can be intimidating, and we want Kactus to make interactions with Git easier and more approachable. Kactus is not a replacement for the functionality of Git, but a tool to enable you and your team to be more productive.
Kactus is built and maintained by a team at GitHub and a group of amazing community contributors as an open source application. It is intended primarily to extend the features of GitHub, not to be an agnostic Git client or replicate the feature set of github.com. While we support very basic functionality that will allow the app to function with other hosting providers, we prioritize work that allows the end-to-end GitHub and GitHub Enterprise experience to shine and takes advantage of the fact that we can closely integrate with GitHub features.
We want to create an inclusive and approachable way for developers to turn ideas into reality, and we see Kactus as critical in reducing the intimidation of working with Git on the command line. Users of all experience levels will continue to benefit from Kactus’s features but when we have to choose between workflows for advanced Git users and workflows for beginner Git users, we prioritize beginners. Additionally, we think it’s foundational to support solo development, but our unique value comes from combining the power of GitHub with the convenience of working locally so that you can collaborate with your team easily. This also means Kactus will likely not support workflows that are unique to your team, against documented best practice, or different from the vast majority of developers.
GitHub has millions of possible use cases and we believe that nearly every industry should be using Git. We support its versatility, but when we have to make choices about whose workflows to prioritize, we prioritize those for software developers.
Kactus should be a helpful tool for beginner developers, but it is not explicitly a teaching tool. It is fundamentally to help you get your work done faster and more effectively, in a way that is consistent with and encourages best practices.
*We define a workflow as a path that users take toward achieving a particular goal. An example is a “merge” workflow, where the goal is to bring work together that was done in different places.