The goal: an app hosting system that is emergent from that which is hosted.
The beginning: a component consisting of one UI button that when clicked begins a component creation/extension process that can both construct its own self and any larger system composed of self-emergent pieces. This larger system includes within it this same ability to modify and extend itself.
Primary aspects are the approach to self building and the final user view. WordPress is increasingly adding features that Drupal pioneered in terms of abstracting the notion of what is a “post”, or a “node” in Drupal, to make it easier to add custom content types. You can create a new content type, add predefined or custom fields to it, to create something specific like “Product” or “Article” and to differentiate it from a blog post or web page using different fields. These are CMSy things. In attempting to actually use these systems on both Drupal and WordPress, I’ve found that there is a conceptual difference between the backend user interface for generating these custom content types, and the front end display. Usually, the backend system works well for creating the data schema and editing the data, but there are large obstacles for creating and using the display part work without a lot of custom front end work. The biggest trouble with both the backend and the frontend is that they have strong opinions about how the data is stored in the DB and significant platform requirements for how the data is displayed within the context of the pre-existing WordPress and Drupal way of doing things. Both pretty much require using custom templates and display themes to really make use of the custom types, and even then, the designer needs to know the platform specific ways of doing things. This then spreads the custom types logic out between very different layers: DB storage for data schema, DB storage for data, business logic in a code module, display logic in templates (stored either in a DB or in code), display style in a theme.
One challenge I keep running into is how to abstract this CMS idea of custom content types on the backend side even more, and yet at the same time how to make all the pieces work together even better out of the box on the frontend display and usability side. The Ceptr and Om.Next approaches seem to be heading in similar directions of encapsulating all the parts of a given unit of system into one package that is constructed with specific rules to make it interoperable with other packages. The notion here is more one of self-contained packages that adhere to global protocols of package interoperability. I can imagine abstracting WordPress and Drupal modules further to arrive at a similar place. I can imagine a WordPress Ceptr module that acts as a container for running this new kind of module. This container module could itself be, or include, a module generator for creating new modules, and even for modifying itself, since it’s generated from its own self-emergent creation methods.