could acquiesce in the assumption that most schools have already chosen an educational platform to which they are committed, and opt to make a separate, platform independent community that facilitates the use of the tools and community without trying to replicate or replace the underlying educational platform schools use. Or could undertake to develop an courseware platform as well as the community and tools such that schools could adopt the platform in its entirety. This section describes each of these options with particular attention to the advantages and disadvantages of each and the reality of the software development undertaking entailed.

The rotisserie was the first tool invented. Its core value is its facilitation of one-to-one interaction between students. Much of the potential for the rotisserie lies in the possibilities for interaction between students in different classes, different fields, and even different schools. For teachers to use the rotisserie to its full potential, they need a community and a method of coordinating with others studying/discussing related subjects. This stripped down vision of the kernel includes the community, the tools that are a part of it, and nothing more. The environment would be a membership-based, web facilitated community. It would be accessible on the web by entering a username and password. It would not require installation of any software by the teachers using it or the students using the tools. It would not serve as the courseware for courses or replace the courseware that a professor's university provided for her.

Once inside , a professor would be able to create classes and syllabuses, schedule use of tools, see and collaborate with other professors and classes, and communicate with fellow professors.

Each professor will have complete control over the access of others to his/her plans, materials, and exercises. Professors will be able to elect to keep all materials private, to have them viewable by others without allowing joint participation, to allow certain materials and exercises to be open while others remain closed, to open exercises to participation only by certain categories of professors or by specific professors, and so on. In addition, professors will have the ability to contact each other within in order to discuss and agree on dates and contents of joint exercises.

There are two main advantages to this style of kernel for . First, it allows the development of to focus on its core educational mission. In the first instance at least, developers would be focused entirely on 1) figuring out how to coordinate networked use of tools by disparate groups using dissimilar systems, and 2) developing the tools themselves. They would be free of the potentially large quantity of development work associated with creating a basic courseware platform. In particular, they would be free of the less interesting problem of reinventing the wheel to create the functionality that is readily available in commercial systems.

Second, this style of kernel would in many cases be more easily adopted by professors and institutions because it does not require changing to entirely new courseware. An interested professor could continue to use the commercial (or other) platform used and supported by his university and still have access to all of the tools provided by . To the extent that this allows adoption by those who would not be able to use if it required use of a new platform, this is an immeasurable advantage, especially considering the increased value of the community when it is widely used. Such use of could be promoted directly to professors through existing professor communities. For instance, the cyber-profs listserv, to which many professors of Internet related subjects belong, might be encouraged by Professor Zittrain to try out the tools and each of the professors could try them regardless of the courseware being used by their universities.

However, this kernel design is not the beginning of the ideal, integrated educational software system. It is clumsy. It requires professors to join an additional community and set up classes duplicating their set up on their school's courseware. Students may have to register and authenticate themselves twice on the course website, once to enter the site and separately to use the tools. Data on the classes and the users of the tools will have to be stored remotely from the schools and professors on servers. This design will never have the effect of being completely integrated with a school's system. It does not aid a school in realizing the goal of a complete, integrated, open source educational software platform.

In its ideal form, would be fully integrated courseware and peer-to-peer community. In this form, an entire university could use the platform as its courseware, customizing it as needed for their own information systems. In general, professors would use the website and tools generated for their class by the courseware, and the core community functions would be built-in to the options given to a professor in managing her course website.

The main disadvantage of this kernel design is the extra cost and complexity of developing the courseware itself. It is a difficult project to do well, and one that is not central to the H2O core idea. Fortunately, however, two projects are already underway that have great potential to alleviate this problem. The Open Knowledge Initiative (OKI), is a joint effort of MIT and Stanford, headed by MIT, to develop exactly the open source educational software platform that envisions. It plans to develop a stable kernel that replicates all the functions currently performed by proprietary coursewares but to do it in open source and with the specific intention of allowing it to be more flexible and have a much greater capacity for adding new tools. The only drawback to OKI for our purposes is that it doesn't yet exist. A complete specification is scheduled to be completed by September with development to begin at that point. Thus, in order to begin development of tools, will have to begin work using another platform and expect to join up with OKI as it is ready. Luckily, there are already open source educational software platforms that exist, at least in beginning stages. In particular, ArsDigita, a commercial but open source software development company that focuses on platforms that foster community has recently adapted its standard platform for use as educational software.

The ArsDigita platform, the ArsDigita Community System (ACS), already has a significant programming and development community built around it as well as numerous companies in the business of installing and maintaining it for interested institutions. In opting for this kernel design, might proceed in two ways with respect to a system like ACS. First, it could recognize that ACS could serve as a strong base for and work on top of the ACS platform to create new tools for the ACS courseware environment. ArsDigita would then be in the position of deciding to authoritatively add the tools in to the ACS package as they were developed.This approach has the advantage of working within a well-established community already developed around the software. It has the disadvantage of loss of control of the project from 's perspective. There is little that would stop ArsDigita from adding a new tool, but adding new functionality as serious as the peer-to-peer community envisions might be more complex.Second, essentially "fork" the ACS educational software product by building from the code to create the environment and maintaining it as a separate product from the ACS platform. This could sacrifice the benefits of the community, though it is possible that ArsDigita and the ACS community might be supportive of such a project.

The second major problem with this kernel design is that its potential inflexibility may decrease the likelihood of widespread adoption. As described, this version of would work only for those professors and institutions willing to use as their courseware. Many universities are already committed to software platforms and would be wary of change to an experimental new platform even if they were looking for a new direction. To the extent that the toolset would only be available to those teachers whose universities are using the courseware, the adoption of the core idea would be hampered.

The main advantage of this kernel design is its streamlined elegance and utility. Schools could choose to adopt this platform in place of their current platform, customize it as they liked, and have complete control over it while still getting the benefits of the community and the pedagogical tools created by and for . The clumsiness of duplicative authentication and the extra work for professors in using the tools would be gone. Schools using it would easily be able to see, design, develop and implement new tools in their own environment if they wished. Even students in computer science classes might work on developing new tools as an experiment in a class.

The option we have elected to pursue is a middle ground between the two options described above. The development of will focus primarily on the creation of the tools, built in such a way that they will be accessible entirely through a web interface and can be used individually and a la carte. However, most likely using ACS, we will also create a simplified version of a full platform which will be hosted at the Berkman Center and will make it possible for professors to use as their educational software platform. Thus, a professor will be able to create a course website with integrated functionality as soon as the kernel is complete. Among other advantages, this will allow us at the Berkman Center to run all of our courses on our new platform.

The main advantage of this approach is that it allows the greatest amount of flexibility for professors who wish to try using in their own classes while also keeping the size of the programming project manageable and focused on the core of the mission.