11am, May 19, 2007

Participating:

This session had two purposes. First and foremost, it was meant to be a continuation of the ongoing discussion between Wiki developers on how to make the different Wiki implementations more interoperable. Second, it was an opportunity for Eugene to share his recent user-focused research on WikiInteroperability and preview his upcoming research/vision paper on the topic.

We started by going around the circle and introducing ourselves. Everybody said their names, the Wiki they develop (if they were developers), and the number of Wikis they used on average. Numbers ranged from four to 12.

Eugene explained that for the purpose of his paper, he defined WikiInteroperability as issues involving the use of multiple Wikis, whether or not they were running on the same software. The intent of his paper was to summarize the state of Wiki interoperability, talk about user needs, and propose a path for the future.

Eugene said that there were three axes of interoperability: technical, cultural, and legal. The cultural issues (and developer implications) were the most surprising. The main issue centered around the use case of moving data from one Wiki to another. It's not entirely uncommon, and most users interviewed suggested that "one-click migration" might be somewhat useful. Such a feature implies the need for standard APIs. However, every user with this use case emphasized that they rarely migrated data without subsequently editing the content to make it appropriate for the new Wiki.

The implication is that APIs are not a high-priority for users. That does not mean they should not be pursued. The real value in APIs are in the new use cases they will enable, which are not things that users (or anyone for that matter) will be cognizant of.

Reini noted that WikiRpc already exists. Eugene responded that a number of Wikis have APIs, but there is no convergence among them yet. Sunir noted that AnchorApplications are usually necessary to seriously motivate developers to converge their APIs, citing WIKIWYG as an example of an AnchorApplication.

The other implication is that one of the best things Wiki developers can do to make their software more culturally interoperable is to improve the usability of their software. Specifically, make the behavior of a Wiki's participants as explicit and as transparent as possible, be it through highlighting user-generated content, such as Wikipedia's guidelines, or through culled data, such as the number of editors on a Wiki.

In this vein, Eugene suggested that the lowest-hanging fruit for Wiki interoperability is single sign-on, specifically OpenId. The important takeaway here was that OpenId is not just about single sign-on. It serves as a standard architectural layer for other identity-related services. In this vein, it's advantageous to implement OpenId now, as it solves an immediate problem and sets the stage for solving future ones. Fortunately, many Wikis have already implemented OpenId. We didn't spend much time discussing this, pointing folks to MarkSpakowski's OpenId session later in the afternoon.

Marc asked about WikiCreole. Eugene said that WikiCreole was one of the success stories for WikiInteroperability. First, he noted that markup wasn't as large of a problem among users as one might think. Making sure markup rules were available on the edit page made a big difference (yet another example of how improving your own usability makes your Wiki more interoperable). Second, most users said they didn't worry too much about formatting, figuring that someone else in the community would fix their formatting. Third, WYSIWYG was not a silver bullet, and there remain big issues around the usability and divergence of the different WYSIWYG implementations.

Eugene gave some background on WikiCreole, and also noted that the concept of WikiOhana materialized at the same time. WikiCreole emerged specifically with WikiOhana in mind. Don't frame things in terms of standards. Frame things in terms of two communities converging, and a mish-mashed markup emerging from that convergence. It shifts both the technical and the strategic decisions. Eugene noted that ChristophSauer, one of the main drivers behind WikiCreole, credited Andy's inclusion of WikiCreole as a column in WikiMatrix as a big reason for WikiCreole's success. Several developers noted that while they implemented early versions of the spec, they hadn't kept it current, because the spec was changing too much. We agreed to discuss this more at lunch (see below).

Finally, we discussed "big picture" interoperability. Specifically, Eugene explained that WardCunningham's original vision for Wikis was as a large-scale, distributed, peer-to-peer system. SisterSites was a very rudimentary, concrete step in that direction. Earle noted that he had come up with some WikiRDF to help with this, but had never bothered publicizing it, because he wasn't sure if folks would be interested. We unanimously expressed interest in this, so by the end of the conference, Earle got some information online with the help of some others. See FutureChanges for more on this.

Lunch Followup

The developers in the group decided to have lunch to discuss things further. Marc proposed two topics to discuss in greater detail: WikiCreole and keeping the inter-Wiki developer discussion going in the future. Concrete action items that emerged:

See FutureWikiProjectsCollaboration for more on this.

None: WikiInteroperability (last edited 2009-11-05 15:15:49 by localhost)