The ELMSLN Tool Builder as demonstrated in the video appears to be like a set of magic buttons, which:
- include all sorts of code generation processes to automagically generate a Drupal "install profile".
- use Drush and GIT, behind the (video) scene, to have the output delivered to an appropriate GIT repository, such as GitHub.
For this "magic" to work (without traditional coding), there are a few criteria (challenges) to keep in mind when you're clicking together these types of contributions, as further detailed below.
Do the modules you're using support import / export?
it is crucial that you're using (contributed) modules that do support "export" of the items that the Drupal site builder has put (clicked) together. Modules such as Views, Rules and Flag are known to come with these import/export facilities.
However, if there are also blocks involved, then you're out of luck for such import/export facilities, since the (core) block module does not have these facilities. Unless ... you use the BEAN module for creating blocks (that module will ensure you can also import/export your blocks).
But, assume your contribution also comes with some set of special "roles" ... which you cannot import/export out-of-the-Drupal-box. You'll have to find a way to also make those exportable (hint: there is a module for it ... also!)
How to package the various functions of your contribution?
This is where the Features module joins the game. It is typically used to select (using site building) the various parts of a site (some views, rules, content types, fields, required modules, etc). The result of this is that you (automagically) generate PHP code (behind the scenes), which at first seems like a typical Drupal module (with a .info file, a .module file, etc). You'll typically have "a number of features" (Drupal-like modules), eg just a few, or a dozen or so. Refer to the article about "Creating content types and fields using a custom module in Drupal 7" for an interesting recap of how use Features to "generate" a custom module for creating some content types and its related fields (and module dependencies).
But putting together the sets of these features is really (repeat: really) an art. Because it is extremely hard to not run into the typical issues (pains) of using Features. Refer to my answer to "How to use the Features module in a 3 dev environnement?" for (way more) details about that challenge ...
Version management and migration management?
It's relatively easy to automagically generate a 1.0 version of such contribution. But think about what it would take to later on generate a 1.1, 1.2, or 2.0 version at some point in the future. Yes there is the Features Diff module, but that's only part of the puzzle when it comes to upgrading.
Even if version management turns out to be doable (fairly easy?), what would be the solution to (also automagically?) migrate the existing content created in (say) a 1.0 version of it towards its (say) 1.2 version equivalent. Do you want to restart from scratch (empty content) when you're launching 1.2? Open question (at least for me): if you do not want to restart from scratch, then how would such content migration procedure be generated automagically?
Something like ELMSLN Tool Builder looks easy to get started with it, but the longer you'd be using such contributions, and the more functionality they come with, the more challenging things will become. Don't take "my" word for it, just verify on drupal.org what the maintenance status of most Drupal distributions look like. Yes there are some well maintained, amazing distributions, but also quite a lot that are not.