Openness in Higher Education: Open Source, Open Standards, Open Access

Brian Kelly*; Scott Wilson#; Randy Metcalfe+

* UKOLN, University of Bath, Bath, BA2 7AY, United Kingdom e-mail:
# CETIS, University of Bolton, Deane Road, Bolton BL3 5AB, United Kingdom email:
+ OSS Watch, University of Oxford, 13 Banbury Road, Oxford OX2 6NN, United Kingdom e-mail:


For national advisory services in the UK (UKOLN, CETIS, and OSS Watch), varieties of openness (open source software, open standards, and open access to research publications and data) present an interesting challenge. Higher education is often keen to embrace openness, including new tools such as blogs and wikis for students and staff. For advisory services, the goal is to achieve the best solution for any individual institution's needs, balancing its enthusiasm with its own internal constraints and long term commitments. For example, open standards are a genuine good, but they may fail to gain market acceptance. Rushing headlong to standardize on open standards may not be the best approach. Instead a healthy dose of pragmatism is required. Similarly, open source software is an excellent choice when it best meets the needs of an institution, but not perhaps without reference to those needs. Providing open access to data owned by museums sounds like the right thing to do, but progress towards open access needs to also consider the sustainability plan for the service. Regrettably institutional policies and practices may not be in step with the possibilities that present themselves. Often a period of reflection on the implications of such activity is what is needed. Advisory services can help to provide this reflective moment. UKOLN, for example, has developed of a Quality Assurance (QA) model for making use of open standards. Originally developed to support the Joint Information Systems Committee's (JISC) digital library development programmes, it has subsequently been extended across other programmes areas. Another example is provided by OSS Watch's contribution to the development of JISC's own policy on open source software for its projects and services. The JISC policy does not mandate the use of open source, but instead guides development projects through a series of steps dealing with IPR issues, code management, and community development, which serve to enhance any JISC-funded project that takes up an open source development methodology. CETIS has provided a range of services to support community awareness and capability to make effective decisions about open standards in e-learning, and has informed the JISC policy and practices in relation to open standards in e-learning development. Again, rather than a mandate, the policy requires development projects to become involved in a community of practice relevant to their domain where there is a contextualised understanding of open standards.

Keywords: open standards; open source; open access; quality assurance; advisory services

1 Introduction

The Joint Information Systems Committee (JISC) of the UK education funding councils has been engaged in a long-running process of engaging with the concept of 'openness' in educational technology and digital content. This engagement has moved through several phases, from initial evangelism into today's more pragmatic stance, and effected through the agency of three services:

  1. UKOLN has been charged with the development of the JISC information environment, formerly known as the Distributed National Electronic Resource (DNER), the UK education sector framework for the distribution of published digital content;
  2. CETIS is the Centre For Educational Technology & Interoperability Standards, and has responsibility for the development of open standards to support e-learning;
  3. OSSWatch provides advice and guidance on the use of open-source technologies in education.

Together these three services offer the JISC support at the policy and strategy level on the three strands of 'openness' in technology discourse - namely, open content, open standards, and open source. In each area the emergence of widespread use of social software and distributed systems (the 'Web 2.0' phenomena) has provided a disruption affecting each service and its strategy on 'openness'.

2 Definition of Open Standards

In a paper on open standards it is important to have a clear definition of the meaning of the term. In practice, however, it can be difficult to reach an agreed definition. Rather than attempting to produce a formal definition the following list of the characteristics of open standards is given:

It should be noted, however, that such characteristics do not necessarily apply to all organisations with a responsibility for open standards. For example within organisations such as W3C (the World Wide Web Consortium) discussions on areas in which standardisation will occur are decided by member organisations who have paid the required membership fee. Similarly the initial discussions and agreements on the preferred approaches to the standardisation work may be determined by such member organisations. Also standards produced by organisation such as the BSI (British Standards Institution) are not necessarily available free-of-charge.

3 Why Use Open Standards?

Open standards are important in the development of networked services for several reasons. They aim to:

Support interoperability:
Interoperability is often critical to those creating digital services. There will be a need to ensure that services and data can be used not only within a correct environment, but also across other digital services and across other application areas. A prime purpose of open standards is to provide such interoperability.
Maximise access:
Cultural heritage services normally seek to maximise access to their resources and services. Ideally access will not be limited by constraints such as the device used by the end user; their physical location; their location on the network; etc. or personal factors such as disabilities;
Provide application- and device-independence:
The dangers of lock-in to particular applications or hardware platforms are widely acknowledged;
Ensure architectural integrity:
Unlike proprietary solutions, for which the development and intended usage is likely to be constrained by commercial and competitive factors, open standards which are developed within a wider context can help to ensure architectural integrity across a wide range of scenarios;
Provide long-term access to resources and services:
Long term access to scholarly resources and cultural heritage resources is of particular importance for public sector organisations.

The authors of this paper feel that an understanding of such benefits is widely accepted within the development community. What, therefore, are the barriers to an implementation of a vision based on this approach?

4 The Complexities of Open Standards

The reality is that despite the widespread acceptance of the importance of open standards and the feeling among some that use of open standards should be mandatory in the development of networked services in practice, many organisations fail to implement open standards in their provision of access to digital resources. This may be due to several factors:

Disagreements over the Meaning:
There are many complex issues involved when selecting and encouraging use of open standards. Firstly there are disagreements over the definition of open standards. For example Java, Flash and PDF are considered by some to be open standards, although they are, in fact, owned by Sun, Macromedia and Adobe, respectively, who, despite documenting the formats and perhaps having open processes for the evolution of the formats, still have the rights to change the licence conditions governing their use (perhaps due to changes in the business environment, company takeovers, etc.) Similarly there are questions regarding the governance of apparent open standards, with the control of RSS 1.0 and RSS 2.0 providing an interesting example; this lightweight but powerful syndication format for Web context has a complex history plagued by disagreements over governance and the roadmap for future developments;
Difficulties in Mandating and Enforcing Compliance:
There are also issues with the mandating of open standards. For example: What exactly does 'must' mean? When told you must comply with HTML standards a developer working on a project might first ask what if I don't? Then what if nobody does? They might also ask what if I use PDF instead of HTML? There is a need to clarify the meaning of must and for an understandable, realistic and reasonable compliance regime;
Failure in the Market Place:
It also needs to be recognised that open standards do not always succeed in gaining acceptance in the market place: they are often regarded as too complex to be deployed and the user community may be content to use existing closed solutions and reluctant to make the investment needed to make changes to existing working practices;
Failure to Satisfy User Needs and Expectations:
There is a danger that a development approach overemphasises the importance of open standards to the detriment of the end user and the end user's needs and expectations. It is often tempting to look only at the benefits of open standards for the developer or the provider of a service. We can see the temptation to develop a service based on a rich standard which can address a wide variety of use case scenarios. The danger would be that the end user rejects the service in preference to a simpler one.

Despite such reservations, in reality many IT development programmes are successful. The success may be based on the deployment of agreed and well-defined open standards. However in other cases development work may adopt a more pragmatic approach, making use of mature open standards, but having a more flexible approach to newer standards, for which there has been no time to reflect on the strengths and weaknesses and the experiences gained in their use.

5 Experiences in the UK

The Joint Information Systems Committee (JISC) ( who provide leadership in the innovative use of Information and Communications Technology to support education and research in the UK, have traditionally based their funding of development programmes around the use of open standards. Technical development for JISC's eLib programme, which was launched in 1996, was based on a standards document (eLib, 1996). The document formed the basis of a revised standards document which was produced to support JISC's Distributed National Electronic Resource (DNER) programme (which was later renamed the JISC Information Environment). Standards document (JISC, 2001). This work in turn influenced the NOF-digitise Technical Standards document (NOF, 2001) which was used by the national NOF-digitisation programme, which was responsible for digitisation projects across the cultural heritage sector.

The authors have been involved in providing technical advice and a support infrastructure for JISC-funded development programmes.

Experiences of the QA Focus Project

Although projects funded by the eLib programme were expected to comply with the eLib standards document, in practice compliance was never formally checked. It was probably sensible at the time (the mid 1990s) to avoid mandating a formal technical architecture and corresponding open standards - that could easily had led to mandating use of Gopher! In those early days of the Web, we were seeing rapid developments in the variety of services which were being provided on the Web and many new open standards being developed. However over time, and as the Web matured and the rate of innovation slowed, there was an increasing realisation of the need to provide a more stable environment for technical developments and the corresponding need to address the issue of compliance.

In 2000 JISC funded the QA Focus project ( to develop a quality assurance framework, which would help ensure that future projects would comply with standards and recommendations and deploy best practices (Kelly, 2003). The project's aim was to develop a quality assurance (QA) methodology which would help to ensure that projects funded by JISC digital library programmes were functional, widely accessible and interoperable; to provide support materials to accompany the QA framework and to help to embed the QA methodology in projects' working practices. Liaison with a number of projects provided feedback on the current approach to use of standards. The feedback indicated: (a) a lack of awareness of the standards document; (b) difficulties in seeing how the standards could be applied to projects' particular needs; (c) concerns that the standards would change during the project lifetime; (d) lack of technical expertise and time to implement appropriate standards; (e) concerns that standards may not be sufficiently mature to be used; (f) concerns that the mainstream browsers may not support appropriate standards and (g) concerns that projects were not always starting from scratch but may be building on existing work and in such cases it would be difficult to deploy appropriate standards. Many of these were legitimate concerns, which needed to be addressed in future programmes.

This feedback was very valuable and provided a counter-balance to views which suggested the need for a heavyweight compliance regime which forced projects to comply fully with a technical architecture and corresponding open standards. The feedback led to the development of a contextual framework which is described later.

6 Open Standards: The CETIS Experience

In the late 1990s CETIS began life as the UK IMS Centre, a project funded by JISC to engage in the new IMS (instructional management systems) specification consortium. IMS began developing a series of specifications for XML data and content interoperability for elearning following the emerging paradigm of 'Learning Objects'. CETIS engaged in the development of the specifications, while also engaging with the the UK education community to disseminate information about open standards, promoting a message that placed open standards as the key mechanism for preventing vendor lock-in and supporting long-term sustainability for the newly emerging 'Virtual Learning Environment' technology sector. As the sector developed, CETIS expanded to engage in a wide range of open standards work at a UK, European, and international level.

This message proved very attractive for policy-makers, who were keen to find a new procurement strategy following the unpopularity of the 'single primary vendor' approach that had been used previously within the schools sector, but still needed to provide some form of strategic co-ordination to prevent resources being wasted. Open standards seemed an ideal tool for this policy task: standards could be mandated such that the choice of systems were restricted to those that could conform; these conforming systems could then be more easily replaced by institutions using the interoperability effected by open standards if they were no longer the optimal choice. This style of procurement policy was adopted in various ways by the Learning and Skills Council, JISC, BECTa, and the DfES, and continues to be the key approach of agencies in the UK education sector to this day through initiatives such as the e-Framework 1, the BECTa Learning Platform Framework, and DfES Information Standards Board.

While the overall message has been an attractive one at the policy level, the experience of open standards at a practical level has proved less clear-cut. In particular, the intended effect of interoperability and reduced opportunity for vendor lock-in has not always been well served by the means of open standards. There have been influences from the political, business and technology context of the development and application of open standards that in some cases have served to either reduce or completely reverse the effect of standards on interoperability.

The process of standardisation can be a difficult one for those concerned. For example, the specification process itself was being driven largely by the vendors themselves, for whom it may be argued the interests are not served best by the agenda of open standards. A good example of this is the first attempt by IMS at a standards framework for Learning Management Systems. This was implemented by the company now known as BlackBoard as a 'reference implementation' of the APIs defined by IMS. However, this reference implementation formed the basis of a product (the BlackBoard LMS) that competed with the other consortium offerings, resulting in the collapse of the first standards agreement.

IMS reorganised its efforts and offered a second set of standards based on XML document transfer rather than system APIs. These new standards had their own problems, however. Many of the new specifications offered little real interoperability as practically all aspects of the specification had become optional to accommodate the diverse capabilities of consortium members. Customers attempting to use the specifications to interoperate systems found that their vendors had implemented incompatible subsets of the specification that resulted in data and content transfer requiring costly manual transformation; the very thing standards had sought to eliminate. In response a number of application profiles were developed, the most well-known today being SCORM (2), to improve interoperability for particular purposes.

In some cases interoperability in practice did not match customer expectations. For example, the early implementations of IMS Content Packaging, the specification for open transfer of content by e-learning systems, used an approach one of the authors of this paper calls the 'white screen of lock-in' approach. This involves inserting between the open content manifest, and open (typically HTML) content a layer of proprietary XML metadata containing instructions to a specific system on how to load the content. Other systems importing the content see the table of contents, but as users click on items in the table all they see is a blank screen as the system renders the proprietary metadata instead of the content. This approach was used by both WebCT and Blackboard in their initial implementations; it may be the case here that neither company expected the specifications to be actually used for interoperability purposes, but simply wanted to assert 'conformance'. At this point in the development of the market it is also highly likely that most customers had just taken delivery of systems and were probably not very interested in ensuring they had a clear exit strategy, and were quite happy to take a conformance statement as sufficient evidence of goodwill in terms of future interoperability.

The issue of standards conformance and compliance has been a difficult one within the e-learning community, particularly with the number of competing application profiles developed. The general approach CETIS took was to take the pragmatic step of inviting vendors to demonstrate working interoperability with other partners within a closed environment, giving developers the opportunity to identify and fix issues before exposing interoperability problems to customers. An alternative approach was to take a more rigourous approach to the definition of application profiles with the intent of producing formal conformance tests, which was the subject of the TELCERT project. CETIS was also involved in the development of the RELOAD (3) tool to implement the IMS content specifications in a rigourous fashion to help users overcome interoperability issues. Today, many institutions use RELOAD to fix errors in standards-conformant content, or convert between incompatible implementations.

There has also been the claim from many smaller vendors that the standards developed by consortia (which often require annual membership fees for access) are themselves a form of lock-in. By releasing complex specifications that are difficult to implement, a barrier to entry is raised that only the largest vendors can afford to cross. This accusation has been levelled at a range of standards, most notably the Web Services specification stack promoted by Microsoft, Sun and BEA, which has swelled to an enormous volume of standards weighing in at thousands of pages. Whether this is a result of deliberate conspiracy or a rather monolithic development approach is moot; the overall effect has been that some developers have found WS-* excessively cumbersome and instead embraced various forms of simpler web services based on HTTP and XML (e.g. REST (4)) using simple proprietary API definitions. These proprietary lightweight APIs are the basis of many of the services considered part of "Web 2.0", such as, Blogger, and Google. It should be noted, however, that in another case, IMS QTI, smaller vendors were actually more able to implement a complex specification than the major vendors, so the argument that standards can be raised as a barrier to entry needs to be looked at critically.

Another twist in the open standards story has been the issue of patents and IPR claims. While open standards are generally thought of as being free to use, this is conditional on the licensing of appropriate patents by contributing companies and the copyright policy of the standards organisation. In two recent cases, this has resulted in the 'encumbering' of open standards with patent issues. The first case involved the company ContentGuard, who were granted US patents for a range of technologies concerned with Digital Rights Management (DRM). ContentGuard actively engaged in the standardisation process through IEEE, developing the Open Digital Rights language (ODRL) in competition with their own XML Rights Management Language (XrML). However, they did this knowing that whichever technology customers used, they would still have to pay a license fee to ContentGuard, even if they chose to use the 'open' standard. The ContentGuard DRM patent situation has been the ongoing subject of legal disputes and commercial negotiations (Rosenblatt, 2005).

The second case involved the infamous '44 claims' of the Blackboard patent (see Feldstein, 2006, and Geist, 2006), which covers many of the features of modern e-learning systems, many of which were implemented by Blackboard at its inception as a result of implementing the first IMS specifications. Ironically, this then created the situation where vendors and open-source projects were then unsure whether adopting IMS specifications would also result in patent infringement. The patent issue, combined with the merger of Blackboard and WebCT into a single dominant vendor, have increased the pressure on institutions to create an exit strategy from their existing platform. Open standards should have made this far easier to accomplish this type of technology switch, which will be costly to implement for many institutions involving a large amount of content and data migration.

The use of patents as bargaining power, leverage, and influencer in open standards has been considered in other sectors, for example, Henrik Glimstedt's work on analysing the open standards process within the mobile telephony market (Glimstedt, 2001 & 2000). However, in educational technology patents in open standards have only recently become an important factor as a result of the Blackboard case.

While standards are a technology artifact, the process of constructing a standards involves an interplay of political and economic motives and is not simply a quest for an optimal technical solution. Where efforts on a particular axis are stalled or meet with opposition, a common tactic is for the proponents to find a new venue to pursue standardisation goals; a useful analysis of how the standards process involves the interplay of personal and organisation motives is given in zur Muehlen et al (2005) in their description of the evolution of open standards for workflow, and how various standards bodies have engaged in a sort of dance with various key players moving between organisations to pursue particular goals. In e-learning a similar interplay has been seen with new standards organisation proposed or created in response to the changing political or business context, such as HEKATE and LETSI. Krechmer (2005) set out a set of criteria for openness in standards, covering the areas of participation (open meetings, consensus, due process), dissemination (open IPR, open change, open documents) and usage (one world, open interface, ongoing support) which in practice are hard to reconcile with the practices of standardisation as seen in the organisations CETIS works with. While most specification bodeis have due process, an open IPR policy of some sort, and a one world (i.e. single international standard rather than regionalisation) approach, most do not support open meetings and instead favour a membership payment model. IMS, for example, decided in 2006 to delay releasing draft documents for public scrutiny to provide a competitive advantage for subscribing members; while understandable in terms of marketing membership fees, this violates Krechmer's 'Open documents' principle. Taken together, Krechmer's principles, applied in practice, show there is a great deal of interpretation possible for the meaning of 'open' in an 'open standard'.

To date, a substantial part of the effort of CETIS has been influencing the prevention of unnecessary or conflicting standards rather than the creation of desirable standards. An example of the type of case where standards prevention is necessary is where standardisation is initiated very early in the development of a technology, in a situation where adoption of a standard would genuinely impact on innovation (this is unusual; mostly, the opposite is true, as standards unlock opportunities to innovate). While early standardisation can be very tempting as a 'land grab' technique by pioneers in new types of applications, it can ultimately be damaging to the healthy diversity of solutions on offer as it sets, rather than an interoperability specification, a de jure dominant design which prevents entry into the market by alternatives (Abernathy and Utterbeck, 1978). The elearning standards area was dominated early on by what Baskin, Krechmer and Sherif (1998) call anticipatory standards: "standards that must be created before widespread acceptance of the device or services", rather than responsive or participatory standards. This can be interpreted as "whoever defines the standard designs the future", and provides a temptation to develop standards prematurely.

While there are known caveats and issues in the area of open standards, there have also been some remarkable successes achieved as a result; understanding the critical success factors involved in open standards is an ongoing effort by CETIS. Tim Bray, one of the original developers of XML, considers that the number of successful XML-based standards is very small, and that 5 critical standards (HTML, DocBook, ODF, UBL, and Atom) form the core of achievement in XML standards to date (Bray, 2006). In other sectors, such as mobile telephony, there has been a considerable body of research on the standards process and its contribution to the mobile telephony market (see, e.g., Glimstedt, 2000, 2001; Pfannes provides an excellent overview of sources).

This complex story has informed the evolution of the approach to open standards taken by CETIS, which since procurement as a JISC service in 2006 (as the JISC-CETIS Service) has moved away from promoting adoption of open standards in a fairly unambiguous way to explicitly supporting a more complex message on interoperability. While the goal of interoperability has remained the same, and is at the heart of the strategy of the JISC-CETIS Service, the means by which interoperability is achieved is now seen by JISC-CETIS as having a number of strands and strategies, only some of which involve the use of open standards. The new multi-faceted approach sees a role for a range of technology interventions to achieve interoperability:

Some of these new strands have been added to the JISC-CETIS strategy as a result of observing the development of working interoperability within Web 2.0, where the standards process has, if anything, been even more convoluted and compromised than in the education sector (there are, for example, somewhere from 7 to 9 known variants of 'RSS'; see Pilgrim, 2004). The interoperability that has been achieved using the basic approach of 'Simple, Sloppy, and Scalable' (as Google's Adam Bosworth puts it; see Steinberg, 2005) has been highly successful and enabled large numbers of new services and initiatives. By contrast, the e-learning sector has seen a long period of consolidation with relatively little innovation but increasing costs. In some cases it may be argued that the prevalence of open standards may have actually reduced practical interoperability; for example, the existence of learning object specifications such as SCORM and IEEE Learning Object Metadata, and their place in mandated conformance and procurement regimes, may have negatively impacted the uptake of content syndication formats (RSS, Atom) in education.

This broader approach to interoperability seems to offer a much greater prospect of lasting impact than a purely standards-based approach, as it enables JISC-CETIS to engage with a wider range of communities and stakeholders and to try different strategies to meet particular needs. For example, it allows JISC-CETIS to engage with open-source initiatives such as Moodle and LAMS in a more balanced way in terms of their overall impact and value, rather than keeping a standards-conformance scorecard as a simplistic measure of positive impact. It also offers a more pragmatic basis to look at the role of Web 2.0 services, and wholly proprietary developments such as Second Life, in the evolving picture of e-learning technology.

The CETIS/JISC-CETIS experience represents an evolution in the organisation's understanding of the concept of 'openness' in terms of interoperability as an interplay of many factors. The net result of this new pragmatism is to focus attention on the desired state and the role in which 'openness', in various forms, contributes to progression towards it. Rather than recommending that organisations mandate open standards and enforce their conformance, JISC-CETIS instead encourages interoperability conversations and convergence on common approaches, backed up by simple functional evaluations of interoperability in practice.

7 Open Source: The OSSWatch Experience

Early evidence demonstrated that open source software was used in UK higher and further education institutions in advance of any advisory service being set up by JISC (5). Much as expected, OSS Watch's initial scoping study in 2003 revealed a mixed economy. No institution was maintaining an exclusively proprietary nor exclusively open source environment. That raised a number of questions for a new advisory service.

Why were institutions turning to open source solutions? Institutional policy in this area notoriously lags behind practice. OSS Watch's 2006 survey, for example, found that less than 25% of institutions had any mention of open source in their IT policies (OSS-Watch, 2006). Yet more than 75% investigated open source solutions at every viable opportunity.

The top three reasons that institutions gave for considering open source software (in 2003) were: interoperability, cost, and security. Interoperability, in particular, was a surprise. However, in retrospect it seems clear that the tendency for open source software to conform to open standards was already beginning to reap benefits with the infrastructure IT stack. This connection between open source and open standards needed elaboration if unbiased advice and guidance was to be provided to universities and colleges in the UK.

One challenge that we face initially is purely definitional. What is 'open source software'? There are competing useful guides. The earliest and more philosophically driven movement is free software movement, led by the Free Software Foundation and its Free Software Definition (Free Software Foundation, 2005). A related but less ideologically motivated option is the Open Source Initiative's Open Source Definition (OSI, 2006). The latter is, of course, based on the Debian Free Software Guidelines (Debian Project, 2004). In addition to these there are numerous other more local variations. However, since OSS Watch was established by its funders as an open source software advisory service, it seemed most sensible to accept the OSI's definition of open source software. Thus in numerous places on the OSS Watch site you will find a clear statement that, "For OSS Watch open source software is always software released under an Open Source Initiative (OSI) certified licence" (OSSWatch, 2005).

A clear and consistent statement of what open source software is, however, does not require suppression of alternate characterisations of free software. OSS Watch regularly makes reference especially to the Free Software Definition and encourages institutions to become familiar with the differences in language and intent between the significant groups in this space. Universities and colleges engaging with free and open source software in a sensible fashion cannot be shielded from the complexities of their own engagement. On the other hand, dealing with these complexities head on can alleviate some of the anxiety they may generate for those less certain of their grounding here.

In some respects open source software is better placed, definitionally, than open standards. There appears to be universal agreement that the Open Source Initiative is the maintainer of the Open Source Definition, even if some vendors do not feel bound by the need to pursue OSI certification for licences they describe as "open source" under which they release some or all of their software. For a time this practice can weaken the clarity that an advisory service can provide in its advice and guidance. Fortunately, the open source community is such that most high-profile vendors flouting the norms of the "open source" appellation find the negative public relations it generates to be counter-productive. Recently a number of such companies have reformed their practices and can now be acknowledged as open source companies even by OSS Watch (6).

Whether a project is using an OSI-certified licence is important. It underwrites what can usefully be said about its licensing conditions in the absence of additional paid legal advice. Institutions involved in procurement exercises are not typically interested in software that requires additional legal advice to know what can and cannot be done with it or how it can be further developed, in the case where the source code is provided. This might be one explanation for the slow take up in the UK of the Bodington virtual learning environment (VLE) as against Moodle. Although Bodington was "open sourced" by its home development institution, the University of Leeds, the licence placed upon it was not OSI-certified. This created a challenge since it could not be proclaimed as open source software by those with a strict adherence to OSI-certification as the key marker of open source software. It took some years for the Bodington community to sort this licensing issue satisfactorily (OSS-Watch, 2006b). In the interim Moodle, which is released under the GNU GPL, was able to increase its market share in UK further education colleges to approximately 56% (OSS-Watch, 2006).

However, although an OSI-certified licence is important, it is not the sole determining of software suitability. OSS Watch therefore avoids making specific software recommendations. Instead the principal task is to help universities and colleges understand legal, social, technical and economic issues that arise when they engage with free and open source software. The goal is not the promotion of open source software for its own sake. Indeed, for OSS Watch the choice of proprietary or open source solutions is immaterial. What matters is that institutions have the resources to think through their procurement, deployment, or development IT concerns in a sensible and rational fashion. The best solution for any single institution will depend upon local conditions and individual needs.

This pragmatic approach to advice and guidance is consistent with that employed by UKOLN in its work on standards. It is also a guiding principle in the JISC Policy on Open source software for JISC projects and services (JISC, 2005). This policy is based on the UK government policy in this area and should be seen as an implementation of that policy (7). Neither the government policy nor the JISC policy mandate open source software for deployment or open source licensing for release of development outputs. Rather, both policies draw attention to open source as one possible exploitation route for software which has been developed with government funds. The JISC policy goes further, providing useful guidance notes for those projects wishing to take up an open source development methodology (see, e.g., Raymond, 1997, and Fogel, 2005).

OSS Watch works closely with JISC-funded development project to aid their understanding of open source development methodologies. Since the JISC policy essentially urges projects to "get their IPR house in order at the earliest possible time", early consultation meetings using involve discussions around licence choice. Again a pragmatic approach rises to the top. Licence choice for software development project can be a fraught affair. The tendency to simply choose the licence you have heard most often mentioned is disconcerting. Without presuming to provide legal advice, OSS Watch helps projects think through the options available to them. In the end the choice will remain entirely in their hands, but issues such as compatibility with other code, potential for developing a community around the project, and an initial long term sustainability plan will certainly be explored.

8 A Contextual Approach

We have described some of the limitations of open standards and the feedback we have received from those seeking to make use of open standards in their development work. We have also described the experience of using open source. However, this need not mean an abandonment of a commitment to seek to exploit the benefits of open standards or open source. Nor should it mean imposing a stricter regime for ensuring compliance. Experience has made it clear that there is a need to adopt a culture, which is supportive of use of open standards and open source but provides flexibility to cater for the difficulties in achieving this. This culture and approach is based on:

It is apparent that there is a need to recognise the contextual nature to this problem; i.e. there is not a universal solution, but we should try to recognise local, regional and cultural factors, which will inform the selection and use of open standards.

Over time, in response to the problems outlined, the authors and others have developed a layered approach towards open standards intended for use in development work (Kelly, 2005). This approach is illustrated in Figure 1.

Figure 1: A Layered Approach to Use of Standards and Open Source
Figure 1: A Layered Approach to Use of Standards and Open Source

This approach uses the following layers:

Contextual Layer:
This reflects the context in which the standards or open source software are being used. Large, well-funded organisations may choose to mandate strict use of open standards in order to build large, well-integrated systems which are intended for long term use. For a smaller organisation, perhaps reliant on volunteer effort with uncertain long-term viability, a simpler approach may be more appropriate, perhaps making use of proprietary solutions;
Policy Layer:
This provides an annotated description (or catalogue) of relevant policies in a range of areas, including open standards, open source, accessibility and accountability. The areas will include descriptions of standards, the ownership, maturity, risk assessment, etc. It summarises the strengths and weaknesses of the standards;
Compliance Layer:
This describes mechanisms to ensure that development work complies with the requirements defined within the particular context. For large, public funded programmes there could be a formal monitoring process carried out by external auditors. In other contexts, projects may be expected to carry out their own self-assessment, or take part in peer-assessment with related projects. In such cases, the findings could be simply used internally within the project, or, alternatively, significant deviations from best practices could be required to be reported to the funding body.

It should be noted that, although it is possible to deploy this three-layered approach within a funding programme or community, there will be a need to recognise external factors, over which there may be no direct control. This may include legal factors, wider organisational factors (for example there are differences between higher and further education, museums, libraries and archives), cultural factors, and available funding and resources etc.

It is also important to note that the contextual approach is not intended to provide an excuse to continue to make use of proprietary solutions which may fail to provide the required interoperability. Rather the approach seeks to ensure that a pragmatic approach is taken and that lessons can be learnt from the experiences gained. In order to ensure that the experiences are shared across the development community (and more widely) it will be important to ensure that systematic procedures are in place to ensure that the experiences are properly recorded and that such experiences are widely disseminated.

A requirement that funded projects should document their decisions on the selection of standards, open source licenses, and open source software, and provide reports based on their experiences in their use will help to ensure that such information is recorded in a systematic way, providing this information in an open and easily accessed fashion will help ensure that such information can be widely disseminated. The use of a Wiki, with RSS to allow the content to be syndicated and news of changes to the information, can help to support this.

After the selection and deployment of standards there will be a need to ensure that the standards are being used in an appropriate fashion. One means of ensuring that this happens is the use of a quality assurance framework. A similar approach may also be suitable, with minor modifications, for the selection of open source software, and open source licenses for development outputs.

9 Supporting a Contextual Approach

The provision and implementation of a model which provides a pragmatic approach to the selection and use of standards will not guarantee that appropriate decisions are made and that the selected standards are deployed in the most appropriate fashion. There also needs to be a support infrastructure in place which ensures that technical managers, implementers, designers and others involved in research and development activities are able to make technical decisions which are appropriate for the intended purpose.

A support model which is being developed is illustrated in Figure 2.

Figure 2: Support Model For Use of Standards
Figure 2: Support Model For Use of Standards

This support model is based on the following features:

The contextual model:
This is described elsewhere in this paper. It should be noted that the contextual model primarily intended for use by the development community. The end user community need not be aware of the contextual model that was used as part of the development process;
User engagement:
Engagement with the user community will be essential to ensure the sustainability of the approach - it needs to be remembered that the development approach is not an end in itself, but a means for satisfying the needs of the user community.

There are several user communities involved in development activities. The development community will typically focus on areas related to the standards, development approach and related areas. The user community, in contrast, will often be disinterested in such issues, concerned primarily with use of a service which functions effectively. Although developers should be aware of the needs to address end user needs, it may be difficult to achieve this goal. It should therefore be a requirement of the funding body or organisation which has sponsored development work to ensure that mechanisms are put in place which will ensure that the approaches taken in development will ensure that the needs of the user community are satisfied. In the e-learning space, JISC-CETIS provides a range of Special Interest Groups (SIGs) that have a focus within a particular domain or context, where there is an effort on the part of the organisation to bring together developers and users to promote a better contextual awareness of the role of open standards.

Mechanisms for ensuring the development work is successful in meeting user needs may include:

There will be a need for the development community to promote the advantages of the preferred approaches to development. This could include promoting the advantages of use of open standards. Such advocacy needs to be tailored for the intended target audience, with other developers and end users requiring different approaches;
A wide range of feedback will be required. For example, developers will need to provide detailed feedback on the contents of the resource base, funding agencies on the contextual model and implementation experiences, and end users on the end user service;
A passive feedback mechanism is unlikely to provide useful feedback. A more effective approach would be to provide more engaging mechanisms that act not only as a one-way transfer of information, but provide richer two-way discussions;
The feedback and engagement processes should help to refine those areas in which deficiencies have been identified. This could include over-simplistic or over-complex approaches to the development model.

10 Towards a Contextual Approach to Open Access?

So far in this paper we have looked in some detail at the experiences of advisory services in the adoption and use of open standards and open source software, and how this has lead to the development of a contextual approach and support services to assist developers, agencies and users. How applicable is this work to the promotion of open access?

As with open source and open standards, open access is again clearly a "good thing" in principle, that in practice requires an understanding of the context of use, the policy framework within which the organisation operates, and an understanding of the measures that can be used to assess whether open access - or, perhaps, more accurately, the benefits intended to be realised using open access - have actually been achieved in practice. For example, the "green" and "gold" open access options (Harnad, 2004) could be treated in a similar way to the various approaches to open source licensing, and to choices of open standards. The contextual model would offer a resource base providing detailed information on each approach, a connection to the policy context (e.g. mandates), access to communities where experience has already been gathered on use, and a set of measures for conformance, such as community peer review and availability of outcomes for public scutiny.

A support strategy for open access may use similar mechanisms to those for open source and open access, including advocacy, feedback, and refinement of the resource base in light of user experience and the active engagement and support of a community of use.

In the areas of open standards and open source we introduced the idea of transparency in the decision making process as part of the strategy for a pragmatic approach to adoption. In the case of open access, this would mean organisations and projects publicly documenting their decision on which open access strategy to adopt, or whether not to adopt an open access approach. As noted earlier, it is also important to note that the contextual approach is not intended to provide an excuse to continue to not support open access. Rather the approach seeks to ensure that a pragmatic approach is taken and that lessons can be learnt from the experiences gained. For example, where existing open access strategies do not meet the requirements of particular contexts, and how new or hybrid strategies can be identified that better suit those contexts.

11 Conclusions

This paper has argued that what is needed is a more contextual approach to the open standards. It could be argued that what we need is not a list of open standards or open source licenses, or open access approaches but an process for adopting open approaches which is based on a desire to exploit the potential benefits of open standards, open source and open access, tempered by a degree of flexibility to ensure that the importance of satisfying end users needs and requirements is not lost and that over-complex solutions are avoided. This process could adopt the contextual approach documented in this paper and watch patterns of usage.


[1] ABERNATHY, W. J.; UTTERBACK, J. M. (1978), Patterns of Industrial Restructuring. Technology Review, 80 (7), 1-9.

[2] BASKIN, E.; KRECHMER, K.; SHERIF, M.H., (1998). The Six Dimensions Of Standards: Contribution Towards A Theory Of Standardization. In Louis Lefebvre, A., Mason, R., and Khalil, T. (1998, eds.), Management of Technology, Sustainable Development and Eco-Efficiency, Elsevier Press, Amsterdam, p. 53.

[3] BRAY, T., (2006). Don't Invent XML Languages. Ongoing(weblog). Retrieved from

[4] Debian Project, (2004). Debian Free Software Guidelines, v1.1. Retrieved from

[5] eLib (1996), eLib Standards Guidelines. Retrieved from

[6] FELDSTEIN, M., (2006). The Blackboard Patent Claims in Plain English. e-Literate(weblog). Retrieved from

[7] FIELDING, R.T., (2000). Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, UC Irvine, 2000

[8] FOGEL, K., (2005). Producing Open Source Software. Retrieved from

[9] Free Software Foundation, (2005). The Free Software Definition. Retrieved from

[10] GEIST, M.,(2006). Patent battle over teaching tools. BBC News, August 14, 2006. Retrieved from

[11] GLIMSTEDT, H., (2000). Politics of Open Standards, Modular Innovation, and the Geography of Strategic Patenting in GSM and UMTS Technologies. Division of Innovation, Lund Institute of Technology. Retrieved from

[12] GLIMSTEDT, H., (2001). Competitive Dynamics Of Technological Standardization: The Case Of Third Generation Cellular Communications. Industry and Innovation, 8(1), 49-78. Routledge.

[13] HARNAD, S.; BRODY, T.; VALLIERES, F.; CARR, L.; HITCHCOCK, S.; GINGRAS, Y; OPPENHEIM, C.; STAMERJOHANNS, H.; HILF, E., (2004). "The green and the gold roads to Open Access," Nature Web Focus,

[14] JISC, (2001), Standards and Guidelines to Build a National Resource. Retrieved from

[15] JISC, (2005), Policy on Open source software for JISC projects and services. Retrieved from

[16] Kelly, B., Guy, M., and James, H., (2003). Developing A Quality Culture For Digital Library Programmes. Informatica 27(3) Oct. 2003.

[17] KELLY, B.; RUSSELL, R.; JOHNSTON, P.; DUNNING, A.; HOLLINS, P.; PHIPPS, L. (2005). A Standards Framework For Digital Library Programmes. ichim05 Conference Proceedings. Retrieved from

[18] KRECHMER, K. (2005). Open Standards Requirements. The International Journal of IT Standards and Standardization Research, 4(1), January - June 2006.

[19] ZUR MUEHLEN, M.; NICKERSON, J.V.; SWENSON, K.D. (2005). Developing Web Services Choreography Standards - The Case of REST vs. SOAP. Decision Support Systems 40 (2005) 1, pp. 9-29.

[20] NOF (2001), NOF-digitise Technical Standards And Guidelines. Retrieved from

[21] OSI, (2006). The Open Source Definition. Retrieved from

[22] OSS-Watch, (2005). What is open source software? Retrieved from

[23] OSS-Watch, (2006). OSS Watch 2006 Survey. Retrieved from

[24] OSS-Watch, (2006b). Bodington released under Apache License v2.0. Retrieved from

[25] PFANNES, P. (2002). Strategic Levers in Standardization Processes in the Mobile Communication Industry. Thesis, Center for Digital Technology and Management, Munich

[26] PILGRIM, M. (2005). The myth of RSS compatibility. DiveIntoMark (weblog). Retrieved from

[27] RAYMOND, E., (1997). The Cathedral and the Bazaar. Retrieved from

[28] ROSENBLATT, B., (2005). Opposition Mounts to OMA DRM Patent Licensing Scheme. DRM Watch, April 4, 2005. Retrieved from

[29] STEINBERG, D.H., (2005). Bosworth's Web of Data. O'Reilly Network, 2005. Retrieved from


1 See

2 Sharable Content Object Reference Model. See

3 Reusable Learning Object Authoring and Delivery. See

4 Representation State Transfer. An architectural model for web resources. See Fielding, 2000.

5 See OSS Watch Scoping Study, 2003,

6 Notable here is Alfresco's move to a GNU GPL release of its principal codebase (see A smaller example, but one prominent in the university web content management market is's MySource Matrix (see

7 See

Citation Details

Openness in Higher Education: Open Source, Open Standards, Open Access, Kelly, B., Wilson, S. and Metcalfe, R. Published in "Openness in Digital Publishing: Awareness, Discovery and Access - Proceedings of the 11th International Conference on Electronic Publishing" (ELPUB2007) held in Vienna, Austria 13-15 June 2007 / Edited by: Leslie Chan and Bob Martens. ISBN 978-3-85437-292-9, 2007, pp. 161-174. <>