[_bpo]

It's too bad (and uncharacteristic of mitchellh) that this post is so light on specifics. Were the "previously unknown challenges" simply that not enough people adopted Otto? Or were there actual technical hurdles?

The premise of Otto isn't clearly flawed, so it would be interesting to see specific challenges - even if it's just "the problem space is way too big and not enough people wanted it"

[mitchellh]

I'm happy to answer myself. Previously unknown challenges are just the various facets of building and deploying an application. Its not so much that they were unknown problems so much as the abstraction we designed for doing so proved challenging to solve those problems.

Ultimately, Otto was trying to be a masterless PaaS (Heroku, etc.). When you frame it that way and think about all the things you'll have to solve it becomes challenging. On top of that, we always wanted Otto itself to be fairly "thin" and delegate its difficult duties to the rest of the stack. This required us to build a bunch of features we weren't ready to build into our other products OR risk bloating Otto itself.

Overall, it was too early for us to do.

[newsat13]

Thanks for your comment/insight. I understand what a PaaS is but what does the 'masterless' qualifier mean?

[dkarapetyan]

The selling point was you just do the bare minimum and otto figures out what other specific things you need to get your project up and running. That's not scope, that's magic.

[_bpo]

Lots of useful, successful things appear to be magic (especially in their selling points). Early Heroku is a great example in this space.

I didn't see anything in the initial premise of otto that was technically untenable. We could speculate about the "challenges" - the scope was too wide/unbounded, it was open source, it was a distraction from other company goals, it didn't gain enough early traction - but that's simply speculation without details from the creators.