Here is a summary of what you have seen.

     1. A "cross-jargon interface" is a way for two different communities of practice to build joint artifacts without understanding each others' technologies. In the application-building case we're considering here, the producers are software developers who build reusable business-object resources, and the consumers don't have to be programmers. The consumers connect to the producers' APIs through dialogs, the way the Mac and Windows replaced the need to construct grammatical command-line text by presenting visual choices.

     2. The "connection hypothesis" says that you can think of the data elements the user sees on the user interface as having traveled down static connection paths that carry elements of business objects to elements of the user interface. The wiring language expresses these connection paths. Along these paths there might be one or more "Gateway components" each of which performs a (side-effect-free) transform on its input object, as parameterized in dialog(s) by the person doing the wiring. This approach induces a clean partition of the application, with producer-built business objects on the left and consumer-built static wiring diagrams on the right. An interactive wiring tool enables consumers to build the wiring diagrams and open up the API dialogs in order to parameterize the APIs.

     3. Augmenting the wiring tool by producer and consumer repositories, and adding facilities such as search, turns the wiring tool into a two-sided-market platform.

     4. The two-sided application model, with its business-object resources and no-code static wiring diagrams, is a superior integration technology that will enable non-programmers to build applications using the reusable business objects. The two-sided market can be seeded by offering a superior experience to what Microsoft, for example, offered with Visual Basic of Applications.

Answers to the Four Questions

1. Give a large new community of non-programmer consumers an interface to employ reusable software resources built by producers.

2. Split the application into two parts, one built by producers, one built by consumers, with the interface between them.

3. Create a two-sided market in which building an application is a market transaction between producers and consumers.

4. Jump-start the market by repurposing earlier application-building experience.