• Standards & Architectures DRAFT REPORT PDF [ Download ] (STDS-ARCH-REPORT.pdf - 404.92 Kb ) Preview

The scope and purpose of the report

The SIGOSSEE Project

SIGOSSEE is a 2-year project funded by the European Union in the programme 'Preparatory and innovative actions - eLearning Initiative’. It supports a Special Interest Group on open source software ( OSS) in education, and provides access to publications, discussions and collaborative activities about open source software and education in europe. Since its inception in autumn 2003, the project, with its website at ossite.org, has become a useful focus and resource for educators, developers and policy-makers .

One of SIGOSSEE’s main project outcomes will be a series of reports covering issues of concern to open source uptake, development and success. The reports planned are: Standards and Architectures for OSS, User requirements and usability issues in the development of OSS, Social, cultural and legal issues in OSS, Organisation and management issues, sustainability and support infrastuctural needs for OSS, and take-up of OSS in selected institutions over the lifetime of the project (best practices). A working group has been struck for each of these reports.

The Standards & Architectures Working Group

The remit of the Standards & Architectures working group is to investigate, debate, clarify and report on the ways in which emerging issues in software architectures and interoperability standards can impact the development, uptake and success of open source software for education in europe. Our scope is a bit more complicated: since all three of these areas can have important interactions with any of the others, the Standards & Architectures Working Group will investigate and report on issues which involve or impact on these interactions among the areas.

We will attempt to make recommendations in our final report: ways to improve upon and/or leverage the relationships among these three communities and interests.

Status of this document

This is a very preliminary draft. Due to the recent prolonged illness of the author, progress on the tasks for the working group have been seriously delayed. We expect to make up for this delay over the summer of 2005.

This report has an up-to-the-minute representation on the web at www.ossite.org/research/standards . We plan to use the WG’s collaborative web space to conduct an extensive process of online writing, debate and resource aggregation involving interested experts. To follow the debate, investigation and writing as it progresses week by week, please go to the site or subscribe to the RSS news feeds available there.

The current written version is restricted in purpose to a rough scoping of the field, and a description of the issues which the final written report will try to address.

Overview of the issues

What are “Standards & Architecture s”?

In the design of software, the words ‘standards’ and ‘architectures’ have special meanings which may be confusing to those outside the field; ‘standards’ are not about quality and ‘architectures’ are not about buildings. ‘The term architecture can refer to either hardware or software, or to a combination of hardware and software. The architecture of a system always defines its broad outlines, and may define precise mechanisms as well’ ( Webopedia 200 4). Standards is usually meant in the sense of interoperability: “…the ability of two or more systems or products (usually hardware or software) to work together without special effort on the part of the customer” (Bitpipe Dictionary 2005).

When discussing architectures and standards in the context of open source software, the adjective ‘open’ - as opposed to ‘proprietary’ - is often implied. Open architecture “…allows the system to be connected easily to devices and programs made by other manufacturers. Open architectures use off-the-shelf components and conform to approved standards. A system with a closed architecture, on the other hand, is one whose design is proprietary, making it difficult to connect the system to other systems.” (Webopedia 2004; see also Wikipedia 2005e, Webopedia 200 2 ). Open standards “…are publicly available specifications for achieving a specific task. By allowing anyone to use the standard, they increase compatibility between various hardware and software components since anyone with the technical know-how and the necessary equipment to implement solutions can build something that works together with those of other vendors” (Wikipedia 2005 ; see also Wikipedia 2005b, Perens 2002).

For the purpose of this report, we will assume that ‘standards’ refers to open interoperability standards. In the course of the report we will frequently be contrasting open and closed architectural approaches, and will try to be clear in context about which approach is meant.

Why is this important?

It is probably not obvious that there is even an issue in ‘standards, architectures and open source for education’ unless one happens to be a developer with experience of all three. Why should the rest of us care?

If we do not care about making fundamental improvements in the kind of software available to support learning and collaboration, then we probably need not care about ‘standards, architectures and open source for education’ either. But if we think that there is an opportunity and need for such fundamental improvements, then we should care about how to combine the advantages of open standards, open architectures and open source, and to take those improvements into our own hands. We believe that collaborative, iterative, open source development can and should lead the way in some key areas of educational software. We also think that the development of open standards and open architectures can play a vital role in the success of this enterprise, and that the open source movement can, in turn, be a great support for the refinement and uptake of open standards and architectures.

Innovation and development of new kinds of software for supporting learning is the main area of interest of the Standards and Architectures Working Group (as opposed to open source and standards issues pertaining to existing kinds of software). Educators and policy-makers are in an unusual position: they want to influence the innovation of software, but cannot of course actually develop or even design that software themselves.

In the 1990’s, efforts were concentrated on the development of interoperability standards and specifications to encourage the development of software which would meet educators’ visions of an ecology of rich content and flexible, powerful, personalised features (see for example IMS 2005). In our experience, such efforts to direct the creation of new application areas with astute standards -development work have been crippled by the lack of real-world but flexible software implementations to exemplify the possibilities and expose potential synergies and interoperability issues (Malloch & Attwell 2001).

Over the same period, many educators and theorists attempted to assemble teams, funding and specifications sufficient to ‘do it themselves’ - to create exemplifications of the envisioned software landscape within one project (eg ECOTEC 1998, 2000, Owen 1999). In hindsight, these efforts can seem ridiculously futile: more than one developer is required, and more than one point of view. Worse, without open source licensing, the programming code developed in these projects is orphaned and wasted since it cannot be built upon incrementally. But open source in itself does not solve the problems of co-ordinated collaboration and incremental development; new interoperability standards will probably be needed as well as overarching architectural ideas and component-wise distributed development approaches .

This report, when completed, is meant to assemble, analyse and present the history and folklore of previous and current educational development efforts, and to offer tips and guidance where possible about where the issues are and what kinds of decisions will be have to be taken. We will be concentrating on the ways in which software developers, educators, policy-makers and software designers can combine the benefits of all three approaches to realise some of the opportunities that future educational technologies can offer.

Interoperability Standards

As noted above, in this report ‘standards’ are not about quality but about common, agreed method s by which disparate systems can interact with one another . We are all familiar with at least some interoperability standards, and with some of the organisations with which standards are lodged: standards such as HTML (web content), SMTP (email), TCP-IP (internet connections and communications), or the gauge (distance between) of railroad tracks; organisations such as the W3C (World-Wide Web Consortium), ISO (International Standards Organization) and IEEE (Institute of Electronic and Electrical Engineers). There are many thousands of less well-known standards underpinning the day-to-day running of our modern technology-enhanced lifestyles. New standards are constantly being developed and proposed as new kinds of technology throw up new incompatibilities and new opportunities for interaction with one another.

In this report, our main concern will be with a smallish subset of existing or future standards: open, high-level software interoperability standards of relevance to education. We will briefly explain, below, what we mean by ‘open’ and ‘high-level’. ‘Of relevance to education’ could include standards governing the format and exchange of materials such as elearning content, descriptions, specifications, portfolios or records, or standards specifying the interactions between systems and components which support online collaborative work or deliver elearning content. Another emphasis of the final report will on the distinction between ‘small, loose’ standards as opposed to ‘big, tight’ standards - again, we will briefly explain what we mean by these terms below. While the final report will try to thoroughly cover existing or already-proposed standards, a further emphasis will be on the standards-development process, in particular on how open source development for education can make use of future standards to allow small, disconnected projects to meet large, coherent goals, and on how forward-looking standards-development for education can make use of open source development to clarify its aims and exemplify its merits.

Where do standards come from?

Standards come from many kinds of sources - because standards come in many kinds, scales and scopes.

Some standards originate from long-term and heavy-duty ‘industry-wide’ committee work involving all the major companies in a field (working towards the mutual specification of a framework or product they all need but which none alone could create) - spanning years, spending millions and delivering huge, detailed specification documents. The CORBA standard is an example ( Object Management Group 2005b, 2005b) ; the development and maintenance of programming language specifications is similar in scale and expense.

At the other extreme, single individuals can initiate or influence the specification and uptake of a small standard which encapsulates one simple idea (eg RSS Specifications 2005, Winer 1999). The almost single-handed initiation of XML-RPC ( Win er 1999) makes a vivid contrast with the colossal effort that went into CORBA, since both are intended to specify a ‘binding’ to underpin remote communication between disparate computer programs. Such differences in scale extend to the effort required to make use of or comply with a standard: CORBA is very powerful but very complex and a lot of work to implement with severe restrictions on how it may be invoked, whereas XML-RPC (or SOAP) can be implemented by a single programmer in a short period of time, and is easily and widely employed by web developers and others who require (simple and limited) remote program-program communication but cannot afford to throw away their existing applications in order to employ CORBA. This illustrates the ‘big, tight’ versus ‘small, loose’ distinction we mentioned above. We will return below to the architectural distinctions entailed by this: tightly-bound monoliths versus ‘small pieces loosely joined’ of the sort that have made web-logging successful and which underpin the web itself (Weinberger 2005). In the course of developing the final report, we will frequently be returning to these distinctions.

Another rough distinction related to the origin of standards is between ‘high’ and ‘low’ level standards. By ‘low-level’ we mean a standard which describes the fine details of the operations comprising foundational frameworks underlying a wide variety of application types - for instance moving bytes around the internet or propagating domain-name changes. ‘Low-level’ standards also tend to be ‘horizontal’ - employed at least indirectly by a very wide variety of application types - and require extensive co-operation as in the case of CORBA noted above. ‘High-level’ standards tend to be ‘vertical’ - restricted to narrow application domains, and the kinds of interactions they describe are more meaningful to ordinary humans. For instance, ‘specify the level of educational attainment this content is aimed at’ or ‘post this content to my weblog’. ‘High-level’, ‘vertical’ standards commonly originate with small, loosely organised groups or individuals.

Almost all standards have the following in common though: the software systems affected by the standards existed before the standards were conceived. This need not be the case, however. If a community of interest can be created which agrees on a kind of software they all would like to see developed but which requires co-operation to achieve, standards can be developed ahead of the systems they involve. However, our experience has taught us that purely abstract design of standards-specifications for ‘vision-ware’ is the wrong way to proceed (Malloch & Attwell 2001). Some kind of iterative development, design and real-world usage has to be worked out. Our final report will place great emphasis on elaborating on these lessons and pointing to possible synergies between open source projects and standards development for ‘future learning’.

What is an ‘open’ standard?

The examples we have mentioned so far have all been open standards - everyone has the right to read the standards documentation, and there are well-defined means by which concerned experts can participate in the refinement, maintenance and development of the standards. There are, however, other standards with which we are all familiar but which are not open - they are proprietary or de facto . For example, Microsoft Word encapsulates a de fact standard for document-exchange, and has a specified format for its internal representation of document content. That format is not open, however - it is an in-house specification of Microsoft’s; other developers who might like to add value to a user’s experience by interacting with that document format, interoperating with Microsoft Word are severely restricted by this lack of open-ness. Nor, of course, is there any means by which anyone outside Microsoft could advocate and effect changes to the format.

Proprietary standards can have very damaging effects on the ecosytem of software applications available in an area. For instance, there is nothing to prevent the owner of a proprietary standard from making arbitrary changes to it in future, or from withdrawing support for specific implementations. The blunt fact is that closed standards are often used as monopolistic wedges to stifle competition in neighbouring or related areas - for instance the lack of a Microsoft Office for Linux is an immense drawback for many potential Linux users, while the announcement of a new version for the Macintosh OS-X system in 1998 was taken as a sign of rapprochement between the two companies. The demise of OpenDoc has been attributed to the leveraging of Microsoft document-format standards and the creation by Microsoft of competing, proprietary, less feature-full standards. OpenDoc was a 1990’s innovation in document formats which briefly looked as if it would forever remove well known problems like ‘which application do I need to open this document?’ or ‘how can I get edit a [graphic, chart, data, formatted text, etc] in this [word-processing, graphics, database, etc] application?’ ( Wikipedia 2005d ). Closed, proprietary standards make open source projects very difficult; t he Open Office Project has been hampered by this lack of open-ness in its attempts to create a suite of office applications which can be adapted to new purposes or re-engineered to install on minority operating systems.

Are open software standards necessary for education?

Some varieties of software seem to be much less reliant on open standards than others. For instance, it is impossible to conceive of a proprietary world-wide-web, whereas we accept the lack of an open standard for Macromedia Flash content and the developer-world and consumer market seems to trust it and to prefer it to the open standard-based SVG (Scalable Vector Graphics - W3C 2005 ). One rule of thumb seems to be that standards will be important where there is wide recognition that a new kind of software system is desirable, but that it would require co-operation to create it . The most common reason that co-operation would be required is that the proposed software system would by definition and intention have to interact with a variety of existing systems. For instance, the CORBA middleware framework was developed by a very wide coalition of large companies (with one obvious large abstainer) because the intention of the proposed framework was precisely to connect all their disparate systems, and thus all of their individual systems would have to interact with it - all of them benefit from having a common foundation.

We predict that software for education will be like that. That many of the most interesting and important future educational applications will be possible only because they can ‘live in’ and ‘count on’ standards-based software frameworks, foundations and ecologies. In our final report, we will attempt to flesh out this prediction, and to describe some of the possibilities, opportunities and requirements entailed in this vision of the future of educational software.

Some standards already exist ‘for’ education (see for example IMS 2005). These tend to be specialised ‘high-level’ ‘vertical’ standards describing common interactions among existing e-learning environments or institutional databases. Some other existing standards are being leveraged for educational uses by some developers, for instance our own and others’ use of the web-logging and content-syndication standards ( KnowNet 2005). We believe that the most important standards are yet to be conceived and developed (see ‘ Where do standards come from? ’ above). We also suspect that the best applications will initially at least be emergent rather than designed, and that the most likely route to big improvements will small incremental steps leaning on a number of ‘small, loose’ standards - like the web-logging ones - rather than from large-scale ‘big, tight’ system-specification.

Architectural issues

Why are we called the standards and architectures working group? What have architectures got to do with the development of standards and open source software for education? As defined above in the What are “Standards & Architectures” section, by architecture we mean the abstract structure of a software system, its overarching design principles, a broad brush-strokes picture of how a system is put together. Software is complicated stuff - regardless of what the consumer pays for it, it is very expensive in time and effort to create, modify or maintain (bug-fix) a large software system. Many software development projects fail because they run out of time or resources; sadly, open source projects are especially likely to fail. Computer scientists and software engineering experts have tried very hard to understand what happens when projects fail, and to evolve methodologies for reducing the risk of failure. One important part of successful software projects is to have a basic understanding of their overall design from the start - this is the kind of understanding that software experts mean by ‘architecture’. In the world of software engineering, some principles, patterns and motifs of ‘architecture’ have evolved over the years, and when software designers reflect upon and employ this kind of folklore they are ‘discussing architectures’.

Open source projects, especially, need to reflect and plan their architectural designs. In open source projects the labour force is distributed and volatile, and there is no management structure or corporate continuity. In order for a large community of volunteers to contribute effectively to the development of a system, the system has to be openly comprehensible. One of the best ways to accomplish this is to at least work towards a component-based approach to the design of open source systems.

Component architectures

One architectural distinction will be especially important to us as we develop this report: open, component architectures versus closed, monolithic architectures. Both approaches try to accomplish the same range of planned-for behaviours, but a component-based approach ( Wikipedia 2005f ) will also try to prepare the system for future feature requests and bug-fixing by factoring the designed-for behaviours into logical kinds and breaking the system up into smaller chunks which each particularly implement a subset of the behaviours of the whole system. Some of the components in such a system often will have strictly internal purposes (that is, they implement utilities and services for the rest of the components rather than functionality directly apparent to an end-user). The monolithic-system approach to implementing the same end-user behaviours will do so in the most immediately convenient way given an existing starting-point, often perturbing an existing system without quite understanding it. Component architectures entail more programming than an equivalent monolithic system but have many advantages in the longer term: they tend to be easier to understand and debug, it is much easier to divide the development effort into semi-independent groups working on different components, and a well-understood, well-factored system will be ready for adaptation to new purposes in the future.

In open source projects especially, the component based approach can be useful. It clarifies the division of labour and enhances the common understanding of the system. This is even more important where an open source project is developing some new, innovative kinds of software behaviour - which in the field of education must often be the case. If there are no existing examples of a kind of software, collaborating towards its development can be very hazardous; thus most past breakthroughs of that sort have come from small, compact groups or even lone individuals. Component architectures can help to support large-scale development in innovative application areas.

Even where an overall open source project occupies a place in a well-known application area, adopting a component architecture can enable creativity and innovation ‘at the edges’ of the system - innovations which could eventually become more important than the system itself.

Interoperability standards and ‘small pieces loosely joined’

So far, we have been discussing ‘systems’ as if a system must be one deliberately designed piece of software, but many of the software ‘systems’ we use every day are in fact distributed across several kinds of application. the world-wide-web is a familiar example. For instance, we can reflect on the world-wide-web as ‘having’ an architecture ( W3C 2004 , Wikipedia 2005g , Fielding 2000) even though it was never designed in such a way. Interoperability standards are the lifeblood of such emergent systems.

When we plan open source software projects it is vital to carefully ensure compliance with the existing standards and architectural conventions that allow our applications to ‘play nicely’ with the rest of the Web. Fielding (2000, see also W3C 2004 , Wikipedia 2005g) has encapsulated in the ‘REST’ principles some essential guidelines for software which hopes to ‘live in’ the web. These principles have too-frequently been ignored by web application developers and content designers.

Our own software projects might benefit in other ways from emergent effects: we can try to take inspiration from loosely-bound, standards-based systems like the web when designing our own applications - essentially architecting the pieces of a distributed system one component at a time. In such architectural planning, we must design both standards and software, and the steps taken should be small. For instance, web-logging is an emergent suite of functionalities which was engineered from very small components and a few ‘small, loose’ standards. David Weinberger ( 2005) has termed this approach to architecting for emergent effects “Small Pieces Loosely Joined” .

Architectures, standards and open source projects

To re-iterate some of the reasons why architecture is a key part of our remit as a working group:

• Architectural planning and reflection is important to the success of open source projects
• Component architectures can be especially helpful in open source projects
• Open standards can enable loosely bound architectures and simpler components
• Open source, combined with component architectures, could iteratively build testbeds for future standards-development
• When designing web-based applications, awareness of web architecual principles is essential
• When designing educational software, awareness of the possibilities of ‘loosely joined’ architectures and ‘small, loose’ standards can enable powerful new functionalities to be approached in small, independently useful steps

Service-Oriented Architectures

One of the issues which the working group will be looking very closely at is the leveraging of web service approaches to create powerful distributed systems on the web (eg see Bloomberg 2003).

Open Source Software

We assume that the reader is familiar with the concept of open source software: computer software which is licensed to specifically ensure that its source code is freely available to be viewed, altered or re-purposed. This contrasts with the once-normal case of proprietary-source software: proprietary software is typically purchased as a monolithic application bundle which cannot be unpacked, inspected or altered by anyone except its developer. More information about open source can be found in many places online - Wikipedia 2005c is a good place to start.

For the purposes of this report, we are interested in the open-ness of open source software, rather than its pricing . In other words, we will not be regarding the purchase or licensing cost of the software as important, but will be greatly concerned with the freedom of software developers and others to inspect, change and re-use each others’ programming code.

In the past 5-10 years, there has been an intense proliferation of open source projects, including many which are of immediate relevance to educators and learners. In every case - even those which eventually became very successful - problems were encountered. This report will be interested in understanding the nature of these problems, especially in software-for-education projects, and in looking closely at how lessons and techniques involving standards and architectures can help to address them.

Software for Education in Europe - are there special issues?

Yes - software for education is a special case when considering the interactions among standards, architectures and open source software. Open source is usually not a key innovator of new kinds of software in other application areas , such as office-productivity suites or operating systems. In fact, a very common goal for large open source projects is ‘reverse-engineering’ well-known existing products. Likewise, in other areas of software, the development of interoperability standards typically lags well behind the development of features and behaviors; software vendors innovate independently and only come together to agree standards once usage of new features is established

We think software for education is different. In the case of software to support learning, we believe that open source and open standards can and should innovate, and lead the way in imagining, exploring and creating new kinds of software. Why? Because proprietary development has so far failed to produce powerful support for lear ning and collaboration - for several good reasons .

• Distributed functionality: when imagining scenarios involving software for learning, in most cases the features we would like demand disparate features, functionalities, resources and content to be assembled from disparate sources - in which there is no single location or engine to act as the locus for proprietary development. This makes it ext remely unlikely that a small, visionary developer can create the required software independently .
• Thinking in the market: Vendor planning is limited to existing markets, whereas many educators and software architects have predicted, in the spirit of “i f we build it, they will come”, that the market for educational software and content could grow exponentially if the usefulness of available software took a few key steps forward. Commercial software vendors are not in the business of creating new markets - think Microsoft and the internet.
• Tragedy of the commons: Even if commercial vendors “got” the possibilities of learning and collaboration software, i t is in no single vendor’s inter ests to invest the resources necessary to improve the general opportunities for everyone. Though large new markets might emerge, the initial developer could not be certain of benefitting from those new markets (for instance, Netscape trailblazed the market for web browsers but was squeezed out of that market in less than a decade).
• Educators are not in the loop: Software developers tend very strongly to think they know much more about education than they in fact do know. The converse is generally true for educators and software development. Thus, vendors produce ‘educational’ platforms without any fundamental insights from educators, while educators often fail to understand how learning opportunities could be improved by astute use of appropriate technology.

For the reasons above, we believe that open standards, open architectures and open source will “come first” in the development of the kinds of software that educators and learners of the future will benefit from. This is not to say that there will be no examples of the more conventional life-cycle of vendor -> development -> market -> standards -> open source alternative implementations, but we will largely leave such cases aside for the purposes of this report.

Some interactions involving standards and architectures

Positive effects of open-ness across the three

Where to from here?

This is a very early and preliminary draft of our Working Group’s report. We hope to have introduced some of the concepts and issues which we will be addressing in the final report as it evolves over the next months. The Standards & Architectures area of the SIGOSSEE/JOIN website will be developed in the next weeks as a space for the collaborative exploration of these issues using resource-collection, shared web-logging and ‘team-tasks’ ( www.ossite.org/research/standards ). We will be trying to solicit the involvement of other interested developers, educators, designers, thinkers and policy-makers.

We will intermittently distill the content being created and collected on the website into new drafts of this document, which will be available at the site. By the end of the summer of 2005 we expect to have an extensive resource available there, including a much more comprehensive version of this report.

References & Bibliography