The 1995 wiki was recognizably different. Authors collaborating there called this wiki nature. In 2011 we set out to make a work environment that was recognizably wiki but equipped to do data processing. Now we ask, how is that turning out?
We have a two-fold strategy: maintain an environment of sharing and invent machinery to do work consistent with that sharing. See Wiki App Stack
Wiki has always been careless about names. Each page gives meaning to a phrase. Some become popular. This adds pressure to reconcile the page with its frequent reference. See Ontology v. Stigmergy
With federation we add the dynamic scope of names we call neighborhoods. These grow site by site as we navigate within one of many browser tabs. Neighborhoods join when an author drags a wiki page from one tab to another. A "fork" makes the temporary connection permanent. Thus the federation grows.
With federation we add mechanical composition of function. Pages viewed adjacently host self-assembled computations where each "plugin" renders its own progress on the page under the author's supervision.
A plugin will work better if it is programmed to make due with whatever it finds lined up on the screen when called into service. One discovers useful interactions unplanned by the programmer. Authors leave each other notes suggesting workflows they have found effective.
We are attracted to the notion of affordance developed by Gibson, "The affordances of the environment are what it offers the animal, what it provides or furnishes, either for good or ill." The programmer contributes to the author the ability to construct as is the author's will, not the programmer's intention. wikipedia 
Norman's variation now called "perceived affordance" has been adopted in design and reduced by web economics to calls-to-action and related persuasive technologies. This we reject. We conceal obvious use in favor of unpredictable discovery.
We have adopted some wiki nature in a decision support system for architects of microservices. Our federation experience has thus informed the organization of a centralized system. See Constructing Explanations
Today we set out to reverse the centralization of a now successful system by redistributing the machinery over the federation. As a test case we offer its service to implementers assembled to realize Doug Engelbart's most ambitious vision. See Offer to the DKR Implemeters
This is a test. Can we assemble enough pieces to make wiki a useful repository to guide those assembling the ultimate repository? More importantly, will the federated version outperform the centralized implementation on any or all criteria. We will see.