Developing, but not overdeveloping, a collaborative space

For the past few months, I’ve been involved in the development of the CUNY Academic Commons, a new project of the City University of New York whose stated mission is to “to support faculty initiatives and build community through the use(s) of technology in teaching and learning”. This is no small goal, given the mammoth size and unruliness of CUNY: 23 institutions comprising some 500,000 students, 6,100 full-time faculty, and countless more staff and part-time faculty. The Commons – built on a collection of open-source tools like WordPress MU, Mediawiki, Buddypress, and bbPress – is designed to give members of this diffuse community a space where they can find like-minded cohorts and collaborate with them on various kinds of projects.

My work as a developer for the Commons pulls me in several directions. Most obviously, I’m getting a crash course in the development frameworks that underlie the tools we’re using. These pieces of software are at varying stages of maturity and have largely been developed independently of each other. Thus, making them fit together to provide a seamless and elegant experience for users is a real challenge. This kind of technical challenge, in turn, leads me to consider critically the way that the site could and should serve the members of the CUNY community. How do you design a space where people with wildly different interests and wildly different ways of working can collaborate in ways that work for them? By making the system open enough to accommodate many ways of working and thinking, do you thereby alienate some of those individuals who need more structure to envision the utility that the site could hold for them? How do the choices you make when developing a tool – decisions about software, about organization, about design – mold or constrain the ways in which the site’s uses will evolve?

In light of these varying challenges, there are a couple different things that I would be interested in talking about at THATcamp. For one, I’d like to get together with people working with and on open-source software to talk nuts and bolts: which software are you using, how are you extending or modifying it to suit your needs, and so on. I’m also very interested in talking about strategies for fostering the kinds of collaboration that the CUNY Academic Commons has as its mission. I’m also anxious to discuss more theoretical questions about the design and development of tools that are meant to serve a diverse group of users. In particular, I’m interested in the interconnections between the designer, the software, and the designer’s knowledge and assumptions about the desires and capacities of the end user.

4 Responses to “Developing, but not overdeveloping, a collaborative space”

  1. kfitz Says:

    I’m thrilled you’re coming – I sent my instructional technology folks to look at Academic Commons not long ago, and really want to hear more about what you’ve done so far and where you’re going from here. Not to mention that I’ve been using WPmu and MediaWiki in my classes, and that I’ve got a commitment to Drupal discussed elsewhere. Will very much look forward to talking with you soon.

  2. joguldi Says:

    My response might be a little unorthodox here — but I’m a big fan of guerilla academic use of publicly available tools for sharing, rather than reduplicating walled gardens of our own.

    I’ve blogged about my own community of academics and para-academics in delicious. I also had a lot of joy out of using flickr, rather than omeka, for my undergraduates.

    In both cases, the functionality suits what I need, as a researcher/pedagogue, just fine. Putting the stuff in public, where the tags are findable via traditional methods (not locked in a walled garden), is a choice — in favor of dialogue with the public over control.

    It isn’t the choice for everybody, but it’s an important criteria to think about for humanities academics committed to the idea of the public intellectual.

  3. Boone Gorges Says:

    @kfitz – Excellent, I’m really looking forward to talking about our respective projects!

    @jouldi – Your response doesn’t sound unorthodox at all! I totally agree with the spirit behind your sentiment. In an ideal world, collaborative spaces would be broad enough to effectively encompass everyone. There would be no need for “walled gardens” (though, I should note, the CUNY Academic Commons is only private insofar as you must be a member of the CUNY community to actually create content there – the content itself is public). But there are a couple of justifications for local communities like the one we’re building:
    – The CUNY community is large enough to support it
    – The members of the CUNY community share a culture that is in many ways unique to the institution, which means in turn that the kind of space that might work for them is not necessarily the kind of space that works for the more general public (or even the more general academic public)
    – Perhaps most importantly, there are many shades of gray between traditional, isolated scholarship and open, fully collaborative scholarship. Even if true openness is the ultimate goal (which is an idea that has strong arguments in its favor, even if it’s not 100% certain), to make it the only alternative to the traditional ways threatens to scare off too many scholars who are mildly uncomfortable with the idea of sharing. The partially closed nature of the Commons provides some protection for these individuals.

  4. Matt Says:

    @kfitz Boone is great — I’m so glad that you two will have a chance to meet.

    @joguldi A walled garden? A walled garden?!!!! You’re killing me, @joguldi!!

    We imagined the CUNY Academic Commons as the antithesis of a walled garden, since a walled garden was exactly what we had in Blackboard (or in Sharepoint, which some administrators pushed for). Instead, we wanted a site that would be built according to the ethos of open-source, guerrilla communications that you’ve described.

    What we’ve tried to do is to build a stable space that could serve as an aggregation point for each member’s content, so that every guerrilla could build elsewhere as she wished but could also have a base camp on the Commons (sorry for the tortured metaphor). We chose to go with WordPress precisely because it plays well with services like, twitter, and flickr. The idea is that members of the site can continue to use those services, but can simply import their feeds into their Commons spaces so that they can share that information in the context of the CUNY community. Since, as Boone points out, most of the site is out in the open, I’m not sure how or why you see it as walled.

    The issue that Boone’s post alludes to, but doesn’t fully articulate, is that we started this project to deal with a problem particular to the structure of CUNY that Boone describes: we have 23 campuses in a very small geographic area; although we all try to keep up with one another, the members of one campus often don’t know what people on another campus are doing. And so, the idea of building a central, collaborative space — one that would bring a greater sense of unity to the university — began. And yet, as Boone’s title implies, we’ve taken pains not to be overly prescriptive. Our goal has been to create an organic site that would take its cues from its members and from its nascent, growing community.