Craig Perue was appointed as the first staff member in the Instruction Support Systems unit in the IT department of the largest University of the West Indies campus in 2003. Craig was responsible for stimulating faculty adoption of WebCT which was being implemented across the University that year. The programme was so successful that the campus outstripped its budget for WebCT licenses which then allowed Craig to lead the evaluation of open source alternatives and one of the largest early implementations of moodle (15,000 students) in January 2004. As the manager of the campus’s educational technology practice, he led the campus’s re-branding and development of moodle as OurVLE and the campus’s migration away from WebCT, as well as the successful evangelization of moodle throughout the University and the English-speaking Caribbean.
Author - Craig Perue, "Not IT, not Business Processes, but Organizational Culture". Originally submitted June 14th, 2007 to the OSS and OER in Education Series, Terra Incognita blog (Penn State World Campus), edited by Ken Udas.
About one week before I joined the IT department of the Mona campus of The University of the West Indies (UWI) as the first staff member of Instruction Support Systems (ISS, the educational technology unit), I sat in a room with about twenty other persons, primarily faculty members, and was trained to use WebCT, as part of the forty or so persons on our campus to be so trained.
The next week I was put in charge of ensuring that faculty members across the campus adopted the system. That was May 2003. Four months later and two IT staff members richer, having worked long hard hours with faculty members on the Mona campus, we had about twenty four courses with over a thousand unique students ready to go for the start of the first semester.
Both the faculty members and I thought this was an immense success - but at that point I was informed that the University simply could not afford that many licenses. They wanted me to ask the faculty members to use another proprietary system with lesser functionality.
In apologizing to my clients, I assured them it would never happen again. I also told them plainly why it had happened, and why it would not recur. The reason it wouldn’t recur, of course, is because we would implement an open source replacement by the next semester. And that was how I came to receive permission from the IT Management team and the blessings of our faculty members to deploy the University’s first open-source enterprise system.
With three campuses - Cave Hill (in Barbados), Mona (in Jamaica) and St Augustine (in Trinidad) in addition to twelve centres in the other contributing countries (known as the UWI-12), The University of the West Indies currently has a total enrollment of over 36,000 students and graduates annually approximately 5,800 students (at undergraduate, graduate and diploma levels).
Below, I will suggest why I think higher education institutions ought to consider open-source software, but first let me quickly gloss over the evaluation, selection and implementation. Other than licensing regime – it had to be an open-source license, there were three other demands imposed by our particular circumstances.
Since WebCT was being aggressively implemented by the Distance Education Centre and the other two campuses, the replacement would need to be implemented as soon as possible to reduce the number of persons who would need to be re-trained for the entire University to adopt the FLOSS replacement.
Because the influential, tech-savvy first adopters across the University would be among the WebCT user base by the end of the first academic year, the replacement system would need to have a low learning curve relative to WebCT for these persons and at the same time provide additional value other than cost-savings (since their campuses could afford WebCT).
Although 2003 marked the official launch of the first University-wide LMS implementation, several other LMSs were already in use or proposed for use in 2003 by individual departments, and so any replacement system would need to provide an equivalent or more powerful set of features.
By early October 2003 the evaluation had begun with literature reviews, visits to other institutions, and discussions with faculty members and academic leaders to gather requirements. A few courses were deployed on WebCT to help us in the information gathering process.
The evaluation processes were very inclusive and the University-wide dialogue was facilitated in part by a discussion group on the development instance of Moodle. During the second semester, the consensus on the Mona campus was that we would deploy Moodle as the campus’s LMS, and we voiced our hope that the other campuses would follow as soon as summer of that year.
At Mona we led the indigenizing process by creating a UWI theme for the user interface, integrating it with our central authentication system, our homegrown Student Registration System, the email system, and later the Badging system (for photo IDs of staff and students). We also took the strategic decision to re-brand it, OurVLE, for Our Virtual Learning Environment.
I acknowledge that there are situations in the Academy in which closed-source proprietary software is still the best choice, for example for my video editing staff and many of our multimedia production situations, although we continue to monitor the evolution of software applications like Jahshaka, MythTV, and Red5. However, I believe those situations are rapidly decreasing as more mature open-source software become available.
From a strategic perspective, there are very sound reasons within the Academy for adopting free (libre) open source software (FLOSS), that are far more important than short-to-medium-term cost savings. Three documents I read in 2003 were especially important influences on my thinking regarding open source software in education. The position I held before moving to the IT department was with the Office of the Board for Undergraduate Studies which included the University’s Quality Assurance Unit. Two of the documents are explicitly about quality: the Baldrige Education Criteria for Performance Excellence and Quality on the Line: Benchmarks for Success in Internet-Based Education. The other was Nicholas Carr’s article “IT Doesn’t Matter” which was published the very month I joined the IT department in May 2003.
My conclusion is different from Carr’s for good reasons. I concluded that publicly funded higher education institutions located in small developing economies that are vulnerable to numerous external forces, such as the UWI, needed to adopt FLOSS very soon. They need to become an active part of the developer community and help determine the relevant software application development roadmaps.
However, I agree with Carr that many information technologies will become commodities that do not confer competitive advantage. Further, as the higher education sector matures, with the incursions of non-traditional for-profit providers, the emergence of corporate universities, and the increasing prestige associated with credentials bestowed by professional associations, and the forces of globalization and regulation by the World Trade Organization, hyper-competition will drive higher education institutions to develop operational efficiencies we do not even imagine now.
Undoubtedly IT will be critical to realizing these operational efficiencies, but even more important will be designing the most efficient processes and systems to automate. However, much of what needs to be done to register a student and provide other student support services is straightforward and will not provide sustainable competitive advantages, as foreign business processes can be bought, brought into an organization, and implemented, as I have heard my colleagues complain for years about the Banner implementation.
How much competitive advantage is an institution likely to derive when it is using the same business processes as everyone else, and has the same cost structure, having bought the same closed-source software packages? Not much, I think. In fact, in time I believe those functions will be outsourced and higher education institutions (HEIs) will only keep for itself the student-, parent-, and alumni-facing functions. These “customer” facing functions are what will allow one HEI to differentiate itself from the others, and the development of a powerful, distinct brand. Some of these functions include:
Course design and some aspects of course development
Teaching, tutoring, facilitation of student learning
Marketing and Communication
It is for the effective delivery of these two first functions why involvement in the FLOSS communities will matter so much for HEIs. For a large, traditional university with a well-established full-time faculty interested in teaching, much like the UWI is, it would make very little sense to outsource course design or teaching, tutoring, or facilitation of student learning, since:
Our teachers know our students better than anyone else and this knowledge can be developed into a competitive advantage for designing courses for them, provided that knowledge is complemented by generic teaching skills, constantly supplemented by teaching scholarship and research, and very importantly by information and communication technologies (ICTs) that allow for rapid adaptation of learning objects, and learning designs. I submit that these ICTs have to be FLOSS, since modifying the tools themselves will be a part of the core business of the University, that is, advancing the technology for teaching and learning. Some aspects of course development, such as the development of web pages and illustrative graphics are not complex and so can be readily outsourced if it is cost-effective. However, some types of learning objects can be quite complex and effective and the organization’s ability to rapidly develop and adapt them could conceivably become a source of competitive advantage.
Teaching, tutoring, facilitation of student learning are way too little understood and complex at present, to be automated. The complexity and difficulty provides an opportunity for the organization to develop deep smarts in that area which can be leveraged for competitive advantage, so outsourcing is an unattractive option. Additionally, since teaching is believed to be one of the most effective means of stimulating learning in the student-turned-teacher, I believe that peer-to-peer and small group teaching and learning will become a larger part of our pedagogical practice, and this too will drive the demand for a wider variety of teaching and learning technology tools. As Ruth Sabean pointed out in the first post in this series, a ‘developer culture‘ in the HEI facilitates this kind of activity and reliance on external software companies to facilitate that kind of faculty and student-driven innovation is unlikely to be as successful.
Probably for all HEIs, but especially for those with tightly constrained budgets, it is critical to find existing open-source applications to build on to get the maximum impact from in-house developers’ time and energy. In the long term then, acceptance of FLOSS in the Academy is essential to support innovation in teaching and learning. Below, I will go into the reasons it is necessary to adopt FLOSS now rather than later.
Open source software is not incidental to my unit’s business model; for very deliberate reasons it is at the very heart of the way we do business.
As professionals we are defined by others by the services we provide them and our relationships with them. Our tools are key to enabling us to provide those services and affect the quality of the services we can provide. It is important therefore to choose tools that empower us as IT professionals, and allow us to serve our clients well and empower them. In designing Instruction Support Systems in 2003, it was my goal to design a unit that would function as a trusted advisor and strategic partner to the UWI teaching and learning community. I believe/d FLOSS was essential to realizing that vision.
In contrast, in quite a number of IT departments in our Caribbean organizations, including our HEIs, IT staff simply install proprietary software and provide Help Desk type support to their clients. This is especially the case for smaller and younger organizations. For most small organizations, because proprietary closed-source software closes off the very possibility in many cases for changing software to meet particular organizational needs, clients learn not to ask for modifications and IT staff learn not to encourage clients to think too much about their particular needs, needs which would be expensive to meet with such license regimes. (In fact one of my Deans still occasionally reminds me I tried to get him to use WebCT.) In some ways then, proprietary closed-source software is fundamentally disempowering. Of course this is not the case for software that meets or exceeds your needs. Also, it is not only license regimes that disempower IT staff and the entire organization; poorly documented or architected software, regardless of license also has a disempowering effect, as does lack of appropriate IT skills for both end users and IT staff.
However, what I am interested in getting at is the significant empowering effects of FLOSS in the enterprise and the enormous positive impacts on organizational culture.
FLOSS gives us the power to say to faculty members and other clients, “imagine what you want, think it through and tell me on Monday morning.” On Monday, we can sit with them in their office, discuss their requirements, and maybe even show them a demo application hosted on a virtual machine somewhere in the data centre. We can continue to refine requirements, timeliness and required resources, and if need be, discuss honestly why it is not feasible to do it until next year or the year after or the next decade.
Clients may be disappointed, but they feel empowered because they know the default response to their requests is “let’s talk about it.” And we can afford that response not because we have an army of developers to throw at any problem, but because the riches of the open source community is now a University resource. (However, I do not mean to suggest that the majority of University staff are already so empowered that the rate of requests is at the desired level. We need to do more marketing and capacity building.) I am very happy that I do not have to worry about my clients rejecting an open-source application because of a stigma attached. Except for the more tech-savvy clients who want to know that the applications they are using are open-source, few clients raise the issue of the license type.
It is relatively straight-forward too to see how involvement in the FLOSS community allows me to rapidly align or re-align the IT unit with the organization’s strategic goals. Not having to worry about adding to the significant software license burden (which are called mandatory costs here at UWI), long procurement periods, context-free vendor presentations, political jockeying with other units for scarce resources, means I can get the software installed with at least three times the efficiency and even greater responsiveness to changes in organizational priorities, than if I were trying to use equivalent proprietary software in most instances. This has allowed us to focus some of that saved attention on implementing proper control and service management frameworks using the Control Objectives for IT (COBIT) and the ITIL Service Management framework.
What really excites me too is that using open-source software allows me to co-imagine and implement an academic IT architecture that we could never afford to implement using proprietary equivalents. Here is a list of some of the server applications we have been working with since August 2006 and expect to work on for another two years. I look forward to discussing other possible choices with you.
| Installed | To Install |
| OSPI | OpenCRX |
| OJS | ProjectNet |
| Drupal | Alresco |
| MediaWiki | uPortal |
| DSpace | MythTv |
| Pentaho | |
| Red5 |
Finally, and probably best of all, FLOSS allows me to give my staff interesting work to do and allows them to be creative in developing both deep technical skills and client relationship skills that will serve them well wherever in IT they choose to work.
I look forward to discussing some of these issues with you.
11 Responses to “Not IT, not Business Processes, but Organizational Culture”
Craig, Hello. Thank you for this interesting and thoughtful posting.
To kick things off I would like to gather your thoughts on the notion of “Open Source Teaching” that was introduced in James Dalziel’s posting Learning Design and Open Source Teaching, which marries OSS in terms of the “learning code” that underlies learning design and OER in terms on the content that is part of the learning design.
I ask this because of your treatment of “programme differentiators,”
These “customer” facing functions are what will allow one HEI to differentiate itself from the others, and the development of a powerful, distinct brand. Some of these functions include:
1. Course design and some aspects of course development
2. Teaching, tutoring, facilitation of student learning
3. Marketing and Communication
It is for the effective delivery of these two first functions why involvement in the FLOSS communities will matter so much for HEIs. For a large, traditional university with a well-established full-time faculty interested in teaching, much like the UWI is, it would make very little sense to outsource course design or teaching, tutoring, or facilitation of student learning, since:…
coupled with the impact of customization that you value in FLOSS, and the economic benefits of FLOSS that you note in your posting. Are you applying the principles of FLOSS to course design, development, and teaching? Are you or your colleagues at UWI involved with using and developing open educational resources or with Learning Design as defined by James Dalziel? Thanks. Ken
Ken, thanks for the feedback. I do believe that a teacher’s ability to create effective learning designs will be a critical differentiator in a future where Wayne Mackintosh and the other folks at WikiEducator and all those involved in Open Education Resource movements have succeeded in making high quality learning objects common and available to all. Here I am using learning design in the broad sense (as opposed to the narrow technical meaning that James Dalziel explained previously) – simply put – it is how you arrange learning objects and activities (which might include collaborative learning) to achieve specific learning goals, and although I have never thought about it as the “code” of teaching, I think the analogy works. In that analogy, teachers become the equivalent of software architects and engineers deciding the most effective and efficient ways to combine learning objects to meet the needs of their students. In the same way that software architecture positions are more resistant to outsourcing than programming jobs, I expect teachers who develop deep understanding of learning and teaching, and especially of how their students learn most effectively and efficiently, will continue to thrive. However this analogy should not be taken too far – learning design is not intimately bound up with computers and the internet. The lesson plans that our elementary to secondary school (or K-12 for the USA) teachers have created and documented for decades are learning designs, as are the sequences of learning objects and learning activities that our faculty members have created in OurVLE.
Since there are already electronic communities of practice where lesson plans are shared with open-source like licenses I suppose one could say that open source teaching has already begun. Here at the Mona campus, the Dean of our largest faculty agreed that all faculty members should have access to all the faculty’s course websites on OurVLE, which in effect means that they would all be able to see all the learning designs, and importantly, how effective each was. This kind of openness is a good start, but I would be hesitant to say that we practice open-source teaching for two reasons. First, as others have pointed out, open-source is very much about issues of ownership and licensing, and while we have begun considering these issues I do not believe that the UWI’s intellectual property policies as they relate to learning designs or learning objects meet the philosophical requirements of ‘open source’ (as defined by the Open Source Institute) or even ‘free’. The second reason is that we do not practice, on a wide-scale, for learning design or learning object development the kinds of collaboration and innovation that characterize open-source software development, although this may simply be a question of the maturity of the practice and not of its existence. It may also be because we have not implemented the kinds of tools that enable these kinds of collaboration, and am eager to look at some of tools mentioned in previous posts that will help, especially since the issues of open-source teaching across the University’s four campuses have been extensively discussed recently (though not under that name) as part of an executive review of our eLearning policies and practices. We have also recently established a relationship with MIT’s OpenCourseWare project in which we mirror OCW, and I expect this to stimulate discussions within departments about use of and contribution to Open Educational Resources, but I think that these issues are only just beginning to rise to top priority for the majority of our faculty members. I think faculty interest and involvement with learning design as Dalziel defined it is even further down on the priority list. One of the reasons I think we needed to adopt FLOSS early was precisely because it takes a while for the organization to absorb new concepts such as FLOSS and OER and change the business model and organizational culture appropriately.
I would also love to hear suggestions about business models that will support Universities that participate in open source teaching.
Hi Craig, Great read thank-you. With the separate campuses at Cave Hill, Mona and St Augustine you may be interested in the Moodle Networks work we’ve been doing. It’s standard in Moodle 1.8 and allows for a single-sign-on framework