This project is situated within the history of software development.  The full sweep of this history has a ways to go to get to a full century unless you want to go back to Ada Lovelace devising algorythms for Babage's never build Analytical Engine.  Longer than a career but beyond the lifetime of current practitioners.  The birth of ruby and rails is very recent and still in very active development.  The Internet, the Web and web applications are only twenty years old, is it surprising that we are discovering and evolving important core patterns?  Component technologies come onto the scene as open source projects that introduced new technologies and were then adopted widely by software developers.  This adoption is driven by desires to build well engineered solutions that will not be easily obsoleted by the next wave of change, and through a marketplace of competing solutions.  In that marketplace, open source solutions have some superior properties when choosing for technological staying power.  When a commercial vendor owns components that are necessary to build solutions, your code can be made obsolete by the whim or fortunes of that vendor.  This kind of lock-in may be good for a vendor's bottom line, but it is never good for the projects that depend on it.

By strategically connecting these core technologies, the card model can become the bridge between the technological platform and a general content/business model.  We can do any kind model logic and presentation in easy to write modules that are controlled by data rules, and we have a platform to easily implement web-based service oriented components as well as the means to combine a network of these components into a system.  Emerging enterprise architectures are now built with mostly or only this type of component.  If you can also build more of the components with cards, then you have both a deeper platform for sharing components, and components that closer to the space where users and designers interact.  They can better describe and deliver features to use, and systems architects can pay attention to systems and operations issues.  The more systems share this infrastructure, the more effort gets invested at both ends of this scale.

We will begin to see how this will work in the next chapters.  We will be able to build out networked support services that handle the publishing and distribution of card modules that uses cards as its underlying technology.  You'll be able build modules and content on different systems and only move the components onto production systems when they are released or published.