I've had this long-term roadmap in my head for a while, but haven't really written it down in full (certainly nowhere in public), so I figured I'd post here for discussion and posterity.
What is Chassis?
It's easy to look at the current implementation of Chassis and come up with an idea of what it is, but the current implementation is not the full picture.
Fundamentally, Chassis aims to be the best way to run WordPress locally. For everything from running single plugins or themes, through to testing client websites locally, to working on WordPress itself, Chassis should be the best available choice.
It does this by sticking to our founding philosophies:
- Chassis is designed for everyone: Everyone should be able to get Chassis working locally.
- Chassis cannot be everything to everyone: Extensions allow flexibility while staying minimal. We don't do everything out of the box.
- Chassis should be invisible: We need to be frictionless, and adapt to workflows and requirements to work with users, not against them.
Our Pain Points
Chassis has a few key pain points right now where we're failing:
-
We assume too much with our directory structure
We started off as a fork of WordPress Skeleton, and this still haunts us to this day. While the paths configuration has made this easier to deal with, retrofitting Chassis into an existing project is still more difficult than it need be.
This also has non-obvious problems for users, including using /wp/wp-admin/ instead of just /wp-admin/.
We started with the assumption that people would develop entirely within a content/ directory. In hindsight, this has turned out to be an incorrect assumption. While the issues can be fixed in parts, we could use an overhaul to correct this initial assumption.
-
Core development is a pain
Our directory structure also makes it tougher to use a development copy of WP. This means that doing core development with Chassis is tougher than it should be.
As such, we potentially lose core hackers who could be our biggest fans if we provided an easier system for them. We cannot be everything to everyone, but we should reduce the friction here significantly.
-
We are beholden to our upstream tools and providers
Right now, Chassis isn't quite flexible enough to avoid pain from upstream providers. While we try and insulate our users from these pains, we cannot always.
Our two biggest problems are VirtualBox and Vagrant, both of which have fundamental problems that mean reliability isn't anywhere near where we'd like it to be. We are currently coupled a little too tightly to these tools, despite the architecture allowing us to potentially provide better support for other tools. We shouldn't abandon Vagrant, but we should offer alternatives for those burnt by it.
Likewise, the PHP apt-get repository is a potentially unstable source. We suffered from a large shock when the older versions of PHP started disappearing from the repository. Becoming more independent of this would be useful.
-
Speed hinders workflows
That is, speed of performing tasks is a hindrance. Particularly spinning up new Chassis sites, as we recreate the environment from scratch every time.
The original motivation behind recreating these was to reduce download size by using an existing local box (in particular, precise32 which shipped with Vagrant). The problem is, the download size of the included packages is significant, and time-consuming, so this hasn't helped particularly. This also means we're not taking full advantage of linked clones to reduce disk space.
Our Focus
Chassis' core is fundamentally stable, extensible, and flexible. The biggest issues we have are around it, and we should focus primarily on this.
Moving forward, our focus should be on the following projects:
-
The Big Split
The first thing we need to do is to begin splitting the core of Chassis (the puppet directory) out into a new Chassis/Core project. This will allow us to begin isolating the Vagrant pieces of Chassis from the core of Chassis.
This will also allow us to create an alternative Vagrant box which can change the assumptions we made initially.
-
Containerisation
Once The Big Split is complete, we can easily create a container using Chassis Core. IMO, this is going to be a smoother process than providing both Docker and Vagrant support out of our main repo (however, we may want to do this anyway).
This also means we can provide a much more lightweight container.
(Let's call this "Chassis Container".)
-
Desktop Improvements
Chassis Desktop represents a significant goal for us, and is a point of differentiation from other local environments. We should work on improving the workflow, usability, and stability of Desktop.
Once Chassis Container is available, we should allow using it under the hood of Desktop instead. Given the architecture of Docker, this should provide a much smoother experience.
-
Base Box
Simultaneously, we should also work on improving Chassis Box for those who use it. Full VMs offer much more power and flexibility than containers for people who want them, so the experience of using them needs to be first-class.
One of the biggest things we can do here is creating a Vagrant base box, which will simultaneously lower initial install time and reduce disk space usage. We essentially don't lose anything by doing this either.
With these projects complete, the Chassis project will have four fundamental core projects:
-
Chassis Box
The current Vagrant box we have today will evolve from just "Chassis" to "Chassis Box". This will use our brand new base box (although allowing the traditional manual builds when needed).
-
Chassis Container
The new, lightweight development environment, built on the same stable core that powers Box.
-
Chassis Core
This will be mainly an internal project that we use to power Box and Container.
-
Chassis Desktop
The user interface built atop Container/Box and Core, giving everyone the ability to run WordPress locally.
Getting from where we are now to where we want to be will be a large undertaking, but not an impossible one. We have all the pieces and knowledge to make this possible, we just need to execute the strategy to do it. :)
I've had this long-term roadmap in my head for a while, but haven't really written it down in full (certainly nowhere in public), so I figured I'd post here for discussion and posterity.
What is Chassis?
It's easy to look at the current implementation of Chassis and come up with an idea of what it is, but the current implementation is not the full picture.
Fundamentally, Chassis aims to be the best way to run WordPress locally. For everything from running single plugins or themes, through to testing client websites locally, to working on WordPress itself, Chassis should be the best available choice.
It does this by sticking to our founding philosophies:
Our Pain Points
Chassis has a few key pain points right now where we're failing:
We assume too much with our directory structure
We started off as a fork of WordPress Skeleton, and this still haunts us to this day. While the paths configuration has made this easier to deal with, retrofitting Chassis into an existing project is still more difficult than it need be.
This also has non-obvious problems for users, including using
/wp/wp-admin/instead of just/wp-admin/.We started with the assumption that people would develop entirely within a
content/directory. In hindsight, this has turned out to be an incorrect assumption. While the issues can be fixed in parts, we could use an overhaul to correct this initial assumption.Core development is a pain
Our directory structure also makes it tougher to use a development copy of WP. This means that doing core development with Chassis is tougher than it should be.
As such, we potentially lose core hackers who could be our biggest fans if we provided an easier system for them. We cannot be everything to everyone, but we should reduce the friction here significantly.
We are beholden to our upstream tools and providers
Right now, Chassis isn't quite flexible enough to avoid pain from upstream providers. While we try and insulate our users from these pains, we cannot always.
Our two biggest problems are VirtualBox and Vagrant, both of which have fundamental problems that mean reliability isn't anywhere near where we'd like it to be. We are currently coupled a little too tightly to these tools, despite the architecture allowing us to potentially provide better support for other tools. We shouldn't abandon Vagrant, but we should offer alternatives for those burnt by it.
Likewise, the PHP apt-get repository is a potentially unstable source. We suffered from a large shock when the older versions of PHP started disappearing from the repository. Becoming more independent of this would be useful.
Speed hinders workflows
That is, speed of performing tasks is a hindrance. Particularly spinning up new Chassis sites, as we recreate the environment from scratch every time.
The original motivation behind recreating these was to reduce download size by using an existing local box (in particular,
precise32which shipped with Vagrant). The problem is, the download size of the included packages is significant, and time-consuming, so this hasn't helped particularly. This also means we're not taking full advantage of linked clones to reduce disk space.Our Focus
Chassis' core is fundamentally stable, extensible, and flexible. The biggest issues we have are around it, and we should focus primarily on this.
Moving forward, our focus should be on the following projects:
The Big Split
The first thing we need to do is to begin splitting the core of Chassis (the
puppetdirectory) out into a newChassis/Coreproject. This will allow us to begin isolating the Vagrant pieces of Chassis from the core of Chassis.This will also allow us to create an alternative Vagrant box which can change the assumptions we made initially.
Containerisation
Once The Big Split is complete, we can easily create a container using Chassis Core. IMO, this is going to be a smoother process than providing both Docker and Vagrant support out of our main repo (however, we may want to do this anyway).
This also means we can provide a much more lightweight container.
(Let's call this "Chassis Container".)
Desktop Improvements
Chassis Desktop represents a significant goal for us, and is a point of differentiation from other local environments. We should work on improving the workflow, usability, and stability of Desktop.
Once Chassis Container is available, we should allow using it under the hood of Desktop instead. Given the architecture of Docker, this should provide a much smoother experience.
Base Box
Simultaneously, we should also work on improving Chassis Box for those who use it. Full VMs offer much more power and flexibility than containers for people who want them, so the experience of using them needs to be first-class.
One of the biggest things we can do here is creating a Vagrant base box, which will simultaneously lower initial install time and reduce disk space usage. We essentially don't lose anything by doing this either.
With these projects complete, the Chassis project will have four fundamental core projects:
Chassis Box
The current Vagrant box we have today will evolve from just "Chassis" to "Chassis Box". This will use our brand new base box (although allowing the traditional manual builds when needed).
Chassis Container
The new, lightweight development environment, built on the same stable core that powers Box.
Chassis Core
This will be mainly an internal project that we use to power Box and Container.
Chassis Desktop
The user interface built atop Container/Box and Core, giving everyone the ability to run WordPress locally.
Getting from where we are now to where we want to be will be a large undertaking, but not an impossible one. We have all the pieces and knowledge to make this possible, we just need to execute the strategy to do it. :)