The article was publicized with a tweet asking “Why haven’t #wikis revolutionized scholarship?”

Of course, I’d rather ask “how have wikis impacted scholarship?” — though that’s less sexy! First, the largest impact is in technological infrastructure: it’s now commonplace to use collaborative, networked tools with built-in version control. (Though “wiki” isn’t what we’d use to describe Google Docs nor Etherpad or its many clones). Second, wikis are ubiquitous in research, if you look in the right places. (nLab, OpenWetWare, and numerous departmental wikis). Third, “revolutions” take time, and academia is essentially conservative and slow-moving. For instance, ejournals (~15 years old and counting) are only just starting to depart significantly from the paper form (with multimedia inclusions, storage of data and other, public comments, overlay  journals, post-publication peer-review, etc). Wikis have been used for teaching since roughly 2002², meaning that academic wikis might be only about 8 years old at this point.

Other responses: Viva la wiki, says Brian Lamb, who was also interviewed for the article. Daniel Mietchen thinks big about the future of wikis for science.

.

1. I used to be AcaWiki’s Community Liaison and now contribute summaries and help administer the wiki.
2. see e.g. Bergin, J. (2002). Teaching on the wiki web. In Proceedings of the 7th annual conference on Innovation and technology in computer science education (pp. 195-195). Aarhus, Denmark: ACM. doi:10.1145/544414.544473 and related source code

James Lyng, Julie Letierce, Brendan Smith, and Dr. Brian Wall produce these videos with in collaboration with DERI scientists. Drawings are by Eoghan Hynes and James Lyng.

Watch the series at DERI Galway’s youtube video channel.

My voiceover role came thanks to Julie’s instigation, since I had narrated a screencast for our colleague Peyman Nasirifard’s Conterprise project.

I was happy to browse the proceedings while lounging. The papers I mark show up in my personal schedule and in a reading list.

I think it’s an attractive alternative to making a paper list by hand, using some conferences’ clunky online scheduling tool, or circling events in large conference handouts. If you keep an iPhone/iPod in your pocket, the app could be used during the conference, but I might also want to print out my sessions on an index card. So exporting the list would be a good enhancement: in addition to printing, I’d like to send the list of readings directly to Zotero (or another bibliographic manager).

The advance program embedded on the conference website still has some advantages: it’s easier to find out more about session types (e.g. alt.chi). Courses and workshops stand out online, too.

Wayfinding is hard in on-screen PDFs, so I hope that in the long run scholarly proceedings become more screen-friendly. While at present I find an iPhone appealing for reading fiction, on-screen scholarly reading is harder: for one thing, it’s not linear.

I’d like to see integrated, reader-friendly environments for conference proceedings, with full-text papers. I envision moving seamlessly between the proceedings and an offline reading environment. Publishers can already support offline reading on a wide variety of smartphones: the HTML5-based Ibis Reader uses ePub, a standard based on xHTML and CSS. There’s no getting around the download step, but an integrated environment can be “download first, choose later”. I’ve never had much luck with CD-ROM and USB-based conference proceedings, except in pulling off 2-3 PDFs of papers to read later.

The Journal published issue 1 in December 2007, but work started in April that year. From the beginning, Jonathan Rochkind served as a moving force. His post “Code4Lib journal idea revival?”¹ generated a number of responses, in part because he made it sound so easy:

So pretty much all we would need is:

1) An editorial committee or whatever. [Maybe some people imagined some
more 'revolutionary' egalitarian type of community process, but I figure
keep it simple, and an editorial committee seems simple, and also
provides some people who have explicitly taken responsibility for
getting things done.]
2) A place to host it. [maybe some kind of "institutional repository"
software would be cool, but in a pinch seems to me a WordPress
installation would do. Keep things simple and do-able and good enough is
my motto. I'm sure one of our institutions would donate server
space/cycles for a WordPress installation for such a journal. ]
3) Maybe a wiki would be nice for editorial commitee discussions.
4) Maybe a simple one page description of the mission of the journal and
what the journal is looking for in articles. The editorial committee can
work on that on the hypothetical wiki.
5) Some articles. The editorial committee can solicit some for the first
‘issue’.

Step 6: Profit! I mean, some e-published articles. No profit, sorry.

After that post, 10 of us stepped forward to decide how to get the Journal off the ground. It surprised me how easy some things were: hosting (thanks ibiblio!), getting an ISSN, finding a sysadmin (the incomparable Jonathan Brinley)…

I spoke at Code4Lib2008, my first Code4Lib conference, due to Jonathan Brinley’s interest in sharing our publishing methods and Jonathan Rochkind’s encouragement. While we looked at other systems, we chose WordPress as a platform, for its simplicity and its customizability. Jonathan Brinley had put in a proposal to Code4Lib2008 to talk about the Journal’s customizations² He graciously shared the podium with me and Ed Corrado to co-present “The Making of the Code4Lib Journal”

Since then, the Journal has gone CC-BY (thanks to DOAJ’s prodding and to qualify for the SPARC Europe Seal for Open Access Journals) and agreed to indexing in EBSCO. We’ve published numerous articles (73 + 9 editorials, if I’ve got the count right), from authors on at least 3 continents. All in all, a great first couple years!

While I’m sad to be leaving the Journal, I’m delighted to have been a part of it. A strong Editorial Committee, with new blood in the form of 5 new editors, makes it easier to pull back from this project. As Tom Keays said when introducing issue 7: Code4Lib Journal, Long May You Run!

1. April 11, 2007 to Code4Lib listserv
2. The customizations are documented on the Code4Lib wiki, part of a category about the Code4Lib Journal.

MediaCommons has just announced funding from the NEH to create “digital portfolios”:
“Given this proliferation, what we need as scholars may be less a system that will manage our communication for us than a system that will allow us to manage our communication, a system than recognizes that the key aspect of scholarly communication into the future may be less the distribution of the products of our research than the management of the social networks through which our research is distributed.” [emphasis mine] MediaCommons as Digital Scholarly Network: Unveiling the Profile System. Via @kfitz.

So scholars don’t have to roll their own,¹ or depend on dubiously-funded startups.²

While the announcement implies “less is more”, Kathleen’s sample profile strikes me as a lifestream. Streams themselves are more “more” than “less”. (‘Firehose’ comes to mind.) So streams alone aren’t going to solve scholarly communication. But streams can be sliced and diced any number of ways. First the data. Then, if there’s interest, maybe some services.

1. Personally I’m all for rolling your own. At least in theory. The first lifestream I ever noticed was code4lib’ber Mark Matienzo’s self-hosted planet , which aggregates his blog posts (both personal and work), tweets, youtube uploads, delicious bookmarks, and last.fm scrobbles. Brilliant, but thus far I’ve been too shy & lazy to follow suit.
2. FriendFeed popularized lifestreams. When Facebook bought FriendFeed back in August, my networks of librarians and scientists had several discussions of alternatives for scientists and other scholars.