A lot of PHP applications or websites (especially small ones) just require a basic LAMP stack at a bare minimum to work fine - e.g.: the success of XAMPP/WAMPP/CRAMP/TRAMP/BAMP/CLAMP whatever. (Yes, there's plenty of extras that could/should be added for doing things the right way)
For example, a lot of Vagrant LAMP users don't require much provisioning at all. Of the top 10 most downloaded Vagrant boxes [1], two of them are pre-provisioned (or nearly) Vagrant boxes. Homestead [2]: 2,769,045 downloads and Scotch Box [3]: 275,963 downloads.
The biggest problem with these setups is deployment. Vagrant Push [4] requires a little bit too much overhead for this audience. The blog announcement even admits this. Hell, Laravel/Taylor Otwell (the Homestead guys) even built a full on deployment service called Forge [5].
If I had to guess, Otto basically is a hybrid to all this. Like an easy Vagrant and basic Heroku all-in-one to help push their Hashicorp's Atlas product.
I'm definitely looking forward to testing it out. Personally loving Hashicorp.
Mitchell Hashimoto has been supporting Vagrant users for several years now. I wouldn't be surprised if that experience has led him to such a conclusion in regards to the use of Vagrant, e.g. all uses have dependency on a version of Ruby/PHP and some versions of some number of libraries and so on. The same abstractions allow control despite differences at a finer grain.
The number of variations on PHP applications are infinite:
1. Apache or Nginx+PHP-FPM
2. INI Configuration
3. PHP Extensions and their INI configuration
4. Vhost Configuration, especially rewriting rules
5. Docroot in app root, or dedicated directory
This cant possible be defined in a common/generic way and supporting more than 50% of the use-cases.
There is a reason why complex click to configure interfaces exist for PHP and Vagrant with Phansible http://phansible.com/ and PHPuppet.
Doesn't matter. There's always the 80/20 rule. It doesn't have to catter to any and all exotic need. One could always customize further (even script that) after Otto's initialization.
Besides a lot of this variety is because people don't follow best practices, and instead have a hodgepodge of this and that technologies, with this and that settings.
Ruby is pretty standard and I assume PHP is as well being VERY mature. However, outside of the core things vary wildly. People using noSQL or simply using rails-api for some examples. Maybe they can manage this well and allow for variance, but Even somewhat granularly no environment is the same. I have never used Docket or containers, but this seems to be the selling point. You don't use a service to help you configure your environment, but you configure it for docker and you can run docker anywhere a bit can go.
Right, but since this is for microservices that should be not caring where your servers are coming from, just looking in your ENV or generated config, you let Otto make the noSql services and etc.
Ruby: MRI vs. REE vs jRuby vs Rubinius, for starters.
And this choice is solved through a variety of mechanisms that people rely on for other parts of their infrastructure, and feel strongly about.
For my part, this is also a solution that is way too late: We have Docker/Rocket and a range of similar tools. Why do it yet another way, when if you instead build a Docker image, you can take that Docker image and deploy it without having to translate your dependencies to a different format and re-test everything?
Docker is a wrapper around Linux. Vagrant is a wrapper around the entire VM [e.g. Virtual Box or VMware]. Thus Vagrant can be used to manage Windows environments. See the list of Vagrant boxes here:
As far as looking alike goes I think it could end with uses Ruby or uses PHP. A lot of modules will differ for different use cases. I may not need any of the modules another user needs.
Did they do any user research? Doesn't feel like it based on the above statement.