If OnlineCommunitiesAreCityStates, then it makes sense that other online communities would like to build a RoadNetwork between them. This requires connectivity between the core servers of each community. However, most communities only provide the UserInterface without providing some machine interface.
Further, the developers of the main online community are probably volunteers. Even if they aren't, they are motivated to keep the online community coherent within their own world view. This may be a limited world view, not reflecting the full wider population. A SeparationOfPositions? may factionalize the user community if some require some functionality that others do not. The typical solution is to provide both services on the central server, but this can be a maintenance headache for the developers and it requires that they bequeath their time to a project they may not be interested in.
Therefore, create a MachineInterface to supplement the UserInterface. Publish data feeds that other client software (e.g. a WikiClient) can hook into easily and use to extend the site in unpredictable ways. In this way, the community facilitates a LittleEconomy of functionality not available from the core. For example, RichSiteSummary publishes a chronicle of the site. This facilitated UnifiedRecentChanges. The LinkDatabase of a wiki publishes its page graph. This facilitated the TouchGraphWikiBrowser.
Further, if you provide a NetworkService?, create a MachineInterface so that it can be chained together with other NetworkService?s.
In keeping with TheProcessedBook, this method will increase the network "stick" of the community by making it more integral to the fabric of the network of social and technical relationships of its userbase. The more they build upon the StableBase of the OnlineCommunity main server, the more they will be invested in the community, and thus it will simultaneously strengthen CommunityMembers?' emotional bonds with the community as well as create new conflicts resulting from those bonds. Google publishes an GoogleAPI? for this very reason, but it also has a lot of power to ignore people's demands for changes to the API.
But, It may also weaken any sense of boundary and control the community has, and it may radically fragment the PublicCommons? and thus lead to an irreparable SeparationOfPositions?. But to avoid TechnologicalDeterminism, we will point out that there must have been some underlying and prior separation to drive people in different directions to begin with, thus this latter objection is based on suppressing people's differing expression to maintain coherence rather than integrating them. See EnlargeSpace for a discussion of this.
A real problem may be that publishing too much data will allow some malicious attacker to subvert the defenses of the community using some TechnologySolution. Care must be taken. For instance, Google has to police the use of its API so that spammers do not overload the system. Also, the RichSiteSummary feed costs a lot of bandwidth as agents must poll the site continuously looking for updates, rather than the more efficient technique of having the site notify/push when a change is made. The RightToFork the content can be created on a site that does not explicitly grant it by publishing too much data. Google's API has allowed competitors to eat Google results with a TransClusion and thereby steal its ad revenue. Finally, copyright and privacy expectations of the authors on the community should be kept in mind.