This doc may or may not reflect the future of Mastermind. For the time being, consider it rambling braindumps and not canon.
Configurations and metadata are tough because they are entirely arbitrary to the application. I'm planning on having some reliance on external services for discovery but allowing some flexibility so that one can find config info however possible, as long as the data required is accessible in a language-agnostic format that everyone understands (JSON and YAML for instance). Nonetheless, configuration data is not a task I want to tackle because I think it's outside of the scope of this project.
Config requirements are different for everyone, but it's trivial to support common interfaces. This is where the push model of provision works perfectly. We are telling the resources explicitly what to do, not letting them figure it out.
Language bias exists wherever you go, but I don't consider it to be an issue. They absolutely must be considered when developing a system that has a variety of purposes. We are primarily a Ruby shop, but we have Python and Java code as well, so I have to abstract away the differences of each into a common format that everything can speak, i.e. the aforementioned JSON and YAML.
I think Chef does a good job of abstracting the Ruby language. Yes, it still helps if you know Ruby well, but the required knowledge of the language to get started is about as daunting as the configuration syntax of Nagios (well, probably less so. Nagios is a beast). Those with prior knowledge will have an easier time getting started, regardless of the system, and that's unfortunately a problem with no answer. I think we can improve upon it, though. I want the only Ruby requirement to be that you have to have Ruby installed to execute it. The EC2 command line tools come to mind as a good example. I need Java to run them, but I'll be the first to admit I couldn't write a Java app to save my life.
With that said, I do have future plans to curb these fears. After I'm done with the core program, I'd like to convert from using pure Ruby objects to passing JSON objects around the system. The Taskfile format will still exist because I like being able to execute scripts, but we'll have a lot more power by converting those Taskfiles into JSON stored in a location. This will allow us to split up resources and rejoin them into new task lists based on need. And with those in place, I'll work on a web interface and an API that will enable Python and other language wrappers to be written (again, so long as they can speak JSON).