The concept of N=1 is by no means restricted to the consumer level. Take, for example, the marketplace of software engineers as consumers of software tools. One could hardly imagine a market more different from the traditional consumer market. But the same N=1 principle applies exactly: Give the "consumer" (software engineer) the ability to participate in the creation of the "product"(software tool), according to his or her own needs and viewpoint on what the result should be.

Consider how a software tool typically becomes a product. A vendor identifies a well-defined need that the vendor thinks has a significant market. The company then creates a software tool to address that need. Such a tool may have some flexibility and customizability, but it was still created to address a specific market need. Examples include software quality measurement tools and refactoring tools. I call such tools "point solutions" -- they're aimed at a "point of pain" in the marketplace.

My company, Pennington, has taken a different approach, which I think fits the N=1 paradigm. We have created what we call a "meta-tool" -- an expert system for manipulating a wide variety of computer languages using a rules language that the "consumer" (in this case, a senior software engineer) can learn and use. The meta-tool is essentially an "automation factory" the consumer can use to create software engineering tools. Using the meta-tool's rules language, the consumer can create point solution tools that meet his or her specific needs and environment. Because of the power and leverage of the rules language, such a tool can be created with a tiny fraction of the effort normally needed for the creation of a point-solution software tool.

As with N=1 in the traditional consumer market, the result is that the consumer is free to contribute his or her own ingenuity, skills, and domain knowledge to the creation of the product. However, in the case of an expert system meta-tool, the added value of this participation is even greater, because the rules developed by the consumer to implement a point solution software tool are the intellectual property of the consumer, and represent a potential competitive advantage for his or her organization.

How does R=G apply to this situation? The meta-tool rules developed to implement a point solution are sharable and reusable. Suppose a globa organization creates a repository of such rules, in which each point-solution rule set is tagged with keywords describing what it does. Colleagues throughout the organization can then search the repository to see if a needed point solution already exists. If not, a similar solution may well exist that they can modify to fit their needs, and then contribute back into the repository. Thus, they join in the consumer participation, creating a software tool ecology, if you will.

Furthermore, the rules language itself becomes a lingua franca for describing software problems and their solutions, so colleagues in different cultures and with different native languages have a common representation they can reference. (This is analogous to a domain-specific dialect of XML that can be used by different organizations sharing a problem domain.) For example, a Cobol programmer doing commercial applications and a C++ programmer doing scientific applications may have what amounts to the same problem. Since the meta-tool's rules language is itself language-agnostic, both are free to apply a solution created in it to their specific situations.

A key point of this scenario in terms of both N=1 and R=G is that the consumer is in control of the product; that person doesn't have to go to a tool vendor, hat in hand, asking for new or enhanced tool capabilities -- hoping that the vendor's development resources, release schedules, and marketing strategy will allow it to create the solution the consumer needs, and having no choice but to either wait until the vendor does so or try to find another (probably incompatible) tool vendor.

The meta-tool vendor thus becomes a meta-vendor. It is my belief that the concept of "meta" will play an increasingly important role in the IT market, providing as it does a more abstract and powerful view of IT. Two currently hot examples are virtualization (a meta computing environment) and XML (a meta representation).

We can also see this at the consumer level, with Web sites that provide an environment in which non-programmers can create "lite" applications such as mashups and Web "gadgets."

An additional consequence in the software engineering market is that the availability of meta-tools will tend to separate the sheep from the goats; as fewer and more powerful software engineers use meta-tools to perform an increasing proportion of the software engineering workload, lesser lights will be rendered unnecessary.