Re-Engineering Education -

Chapter 18 - Conceptual Definitions
 

Summary of basic concepts:

We distinguish between the courseware, the topical content of each course, and the software of the OpenSourceLearning.net system, the platform upon which the courseware is implemented. The software platform must be easily used by individual educators without any more knowledge of computer technology than is required to access email or surf the Internet. Every educator must be able to develop their own courseware, to modify specific topics within each course, and to add topics. The system must be intuitive and very easy to use, in order to ensure maximal implementation of one of the key principles stated on the home page: continuous quality improvement.

The OpenSourceLearning.net software platform itself must be freely available, and designed to become a de facto open standard. Although we support the idea of both open and proprietary courseware, we want to avoid a process of dueling standards for the courseware or the software platform. We want to encourage the widest possible use at the lowest possible cost in money, time and effort. A formal structure such as has developed around W3C (www.w3c.org) is our model.

Just as the proprietary Windows and Apple operating systems now have to justify their greater cost over open source Linux, proprietary courseware will have to justify its cost over free open source courseware. A provision for adjudicating disputes over intellectual property must be derived to preclude actual litigation. We want nothing to stand in the way of continuous quality improvement, neither insisting on all free courseware nor unreasonable levels of grasping intellectual property protection.  Striking the right balance is beyond the scope of this essay, and probably beyond the capabilities of the authors.

The software platform will create and maintain the concept of owner of each instance of a course implemented as courseware. Like the administrator on a computer, the owner will be the user (or group of users) with administrative rights to modify the relevant course, including creating and publishing the course in the first place.

Although we refer to the owner as being singular, in practice a given instance of courseware is likely to be developed by a group. Our model for collaborative development is SourceForge.net, the primary open source development collaboration site.

Continuous quality improvement is where open source principles come into play. As students and reviewers use the courseware, they need to be able to easily log comments in context about any opportunities for improvement they perceive or any difficulties they encountered. Owners of each course implemented in courseware can use these comments and their own perceptions to continuously modify the instruction and the homework database. Anyone can add comments, but only the original author of a given comment or the owner of the referenced course can delete the comment or update the courseware. Provision to exclude abusive commenters will be available, both at the courseware level and at the individual level.

Individual educators (or indeed students as well, if granted permission on an individual basis) can extend any topic within an instance and make themselves the owner of that alternative topic within the course owned by others, with provision for copyright protection for proprietary courses. This could take the form of open modification, but actual use of the alternative by students requires approval by the owner.  In this regard, updates to the courseware follow a course very analogous to software development, testing, approval and deployment. If the owner refuses permission, then the alternative can be presented as a wildcat course, discussed below.

While a course is being developed, access to it can be granted as narrowly or as widely as desired by the owner. While an instance of courseware is in development status, the content can be created, updated, and deleted at will by the owner.

While the software must provide the widest possible latitude for creativity in the development of the instructional courseware components for each course, the minimum scope of each course must be defined, named and bounded by an agreed authority. Initially, this will follow the syllabus of an established textbook to be supplanted by a committee of educators, but in time it could be replaced by legislation. Nothing, however, should constraint the maximum scope of the courseware implementation.  If it should make sense to a given educator to cover topics or concepts in, for example, linear algebra, at the same time as elementary algebra, then there should be no barrier to doing so.

To be complete, an instance of courseware must cover this minimum scope.  Incomplete instances of courseware are acceptable and expected, but will serve as an adjunct to a complete course rather than a stand alone course.

Complete instances of courseware can be reviewed and, once accepted by the peer review mechanism, can then be published. Courseware publication will be directly analogous to peer reviewed journal articles prior to professional publication. The precise mechanism for submission, nominating reviewers, acceptance and rejection is yet to be defined, but is expected to be an amalgam of open source development and peer review publication. We assume that only accepted courseware will be published. Any published instance of courseware will be identified as to whether or not it is complete and accepted.  We envision publication in a universal catalog, but provision will be made for local publication in a private catalog as an alternative to universal publication.

A wildcat instance of courseware will have two or only one of these attributes: complete, and/or accepted, and/or published.  A wildcat instance of courseware may be deliberately incomplete, intended perhaps to serve as an adjunct to a complete course, but may nevertheless be reviewed, accepted, and published. 

Alternatively, a wildcat courseware may be deliberately provocative or disruptive, and face no chance of being accepted by peer review.  But, some of these diamonds in the rough will prove to be valuable despite the opinions of peers, and the opportunity for an alternative approach to be independently validated by results must be available to encourage creativity.  But such alternatives will be identified as such in the catalog.

The precise mechanism of publication remains to be defined.  It must be both authoritative, so that complete and accepted courses are correctly identified as such, but open, so that rejected courses can be published as wildcats.  Our tentative model for this is a moderated forum in which the catalog owners control publication in the catalog.  Open catalogs must be permitted without moderators, and user rankings must determine the position of a courseware entry so that abusers are pushed to the bottom and no one pays attention to them.  Perhaps after a suitably long period of time, entries with no activity can be deleted, on the model of the domain registry.

When a course is being submitted for publication, it must be stable, with further changes to that release level disabled by the software unless the request is withdrawn or rejected.

Once accepted, the course will be given an official release number, with links to all public reviewer comments. Subsequent updates to that release must pass through the same review process, though presumably a much streamlined process. Updates when published increment the release number. Error corrections will similarly follow a streamlined review process.

So far, we have been discussing the conceptual definitions of the instructional components and the underlying software platform. In addition, there are the conceptual definitions of the evaluation process. This separation of instruction and evaluation is a key component of the design. Teach any way you might want, but at the end of the day the student has either learned it or not.

The homework database will consist of specific problems or questions, or - where applicable - of problem templates.  A template can be used to generate different problems from the same template definition, with only a narrow range of variability defined for use by the homework module. Like the courseware catalog, there will be provision for a universal homework database as well as a private, local database.  A local database will also be used in conjunction with courseware under development, for local problems.

Homework is both the practice work associated with traditional homework, and also the evaluation mechanism by which topical mastery is established. However, homework problems from earlier in the same course or from precursor courses will be randomly re-presented to ensure that mastery, once achieved, never decays.  This goal must be optimized so that absurdly basic questions are not presented after some level is reached, though this may have practical limitations. Much work will be required in this area.

We want to let a thousand flowers bloom insofar as instructional instances of courseware are concerned, but the evaluation process is critical to ensuring discipline for students, teachers and administrators.  Therefore, access to the homework database, and the process of submitting problems, problem templates and questions must be tightly controlled.  In general, the educators with access to the courseware will not have access to the homework database, though they will be strongly encouraged to contribute homework problems and questions to build the database.