I've been seeing the phrase "walled garden" a lot in the edublogosphere, and always with a negative connotation. It is a term that seems to carry over from more general usage referring to either media content or wiki pages that are not open to the public. Of course, Walls are Bad, Open is Good. ("Two legs baaaad, four legs gooood!") I am a general advocate for Openness, particularly when it comes to education. But I think we are in serious danger of throwing the baby out with the bathwater.Why would we want a "walled garden" in our online learning environment? There are several reasons. The first one is the same reason why we like to have the option of closing the door to a physical classroom. Sometimes privacy is appropriate. Teaching is about trust. If you want your students to take risks, you have to create an environment that is safe for them to do so. A student may be willing to share a poem or a controversial position or an off-the-wall hypothesis with a small group of trusted classmates that s/he wouldn't feel comfortable sharing with the entire internet-browsing population and having indexed by Google. Forever. Are there times when encouraging students to take risks out in the open is good? Of course! But the tools shouldn't dictate the choice. The teacher should decide. It's about academic freedom to choose best practices. A good learning environment should enable faculty to password-protect course content but not require it. Further, it should not favor password-protection, encouraging teachers to explore the spectrum between public and private learning experiences.
Second, faculty should have the ability to use copyrighted material legally with their classes at their discretion. Would I prefer that they use public domain or Creative Commons-licensed content that doesn't require restrictions on access for legal use? Of course! But who am I to tell faculty members that they can't use that brilliant animation created by the textbook publisher that just doesn't have an Open equivalent? We can and should encourage the use of Open content, but the learning environment shouldn't mandate it. Again, the teacher should have the academic freedom to choose.
Now, a related but separate cluster of issues is around not content but tools. For example, David Wiley writes,
Think about the social software systems people are actually using in numbers these days:
Blogging, like wordpress
Social bookmarking, like del.icio.us
Photo sharing, like flickr.com
Social networking, like friendster
Social search tools, like technorati.com
Mapping tools, like frappr
Comment tracking, like CoComment
Question and answer software, like Yahoo Answers
With the number of users of these tools, and the others in each of these categories, why on earth would we create a new tool in any of these spaces? When critical mass is the single most important part of a network, why would we build another 'walled garden' collection of applications? Why would we trade tens or hundreds of thousands of users in existing systems in favor of an "integrated" collection of these tools?
I see three separate issues all tangled up in this one excerpt. The first issue is whether there is justification to try to reimplement an "educational" version of software when a perfectly good and popular generic version already exists. Why should Blackboard or Moodle have its own blogging tool? Why not just use WordPress? I'm all for agressively re-using existing software wherever we can; in fact, it is one of the guiding principles behind the LMOS. That said, sometimes the generic version of the software doesn't meet specific classroom needs. For example, my colleagues who use Flickr for teaching would like to see some features added that would have great appeal for classroom use but perhaps not so much for more typical uses of that application. So sometimes education-specific implementations are warranted. But in general, the burden of proof should lie with the developers to show that the world needs, say, yet another discussion board implementation.
A second issue that David raises is that the data should be Open. If the value of social software scales with the number of users, the argument goes, then why would we want to wall off students from a massive existing user community? To which I answer, "See above." There are times when privacy is appropriate. Note that there is nothing that precludes the group scoping of any of these applications to allow teachers, students, and other users to make their own choices about public versus private.
The third and final issue I see embedded in David's post is the apparent belief that we have to choose between Open and integrated. (I may be misunderstanding him here.) If that is, in fact, what he is claiming, it is just not true. To choose one of about a bazillion examples, take a look at Flyr, a service that takes the locations of geotagged photos from Flickr and displays them on Google Maps. One of the great aspects about Web 2.0 is precisely the ease with which composite distributed applications, or "mashups", can be created.
Perhaps what David means is that this can't be done in a systematic way? Stephen Downes comments on David's post,
I still think we need to explore and understand better the nature of distributed applications. Tools like Flickr, Friendster and Technorati each try to become, if you will, a destination for people, to aggregate as many users as they can. We need to focus less on these big centres and more on how even unpopular tools can be mashed up and aggregated. There needs to be, if you will, a long tail of Web 2.0 tools - but nobody knows how to do that yet.
Solving this problem--while enabling teachers to make all kinds of choices about their gardens, including whether to have walls--is exactly the goal of the LMOS. The complex architecture that seems to be offputting to some is, in effect, a black box that functions as a router for web services. Stick the services in one end, stick the things that can take services on the other end, and the box figures out how to connect the two for you. If we continue to see a proliferation of web service APIs for these tools, and if we can use technical mechanisms such as WSDL, ESB, and JBI to provide some degree of automagic connection between potential service-providing applications and potential service-receiving applications, then voila! We have a flexible learning environment that enables teachers to re-use and integrate existing tools on a large scale.