At any point in time, there is a college IT director trying to determine whether to upgrade, migrate away from, or stay the course with some software package that the faculty and students rely on to meet their instructional needs. A campus may have outgrown the basic CMS, and the Enterprise version is now needed to bring system performance back to an acceptable level. The CMS provider may have changed code base, requiring major staff retraining to follow the migration path. Costs could be up, service could be down, and new third party tools may not easily integrate. Yet even faced with all of these potential reasons to change, making the decision to do so is never easy. User communities hate change, hate training, and hate repurposing earlier content to work in a new environment.
For most universities, a decision to introduce new software should be made with the expectation that the choice will hold for three to seven years – until the campus again finds its groove. So change is not taken lightly, and the risk of change must be projected over time and discounted back to the present. Then just when you’re about to make your decision – having done focus groups, cost analyses, technical stress tests, and due diligence – someone mentions “open source software,” and new dimensions of system adoption and environmental risk are brought into the mix.
What is the value to your organization of being able to separate software support from software licensing? What is the value, if any, of being able to customize at your discretion the underlying code that runs your campus eLearning system? What could it mean to your campus to join a software cooperative – a community that shares software development and support costs, training resources, and possibly hardware infrastructure? And if some of what you’ve been reading about open source sounds encouraging, should you “bet your career” on this promise and potentiality? Maybe and maybe not. Read on for some background on open source, or just skip to the last section and enter the debate.
A Backgrounder on Open Source
Open source software, software that is obtainable without licensing fees and freely modifiable by the organization using it, has earned a place in the IT infrastructure of the vast majority of educational and commercial institutions. The open source Apache Web server, PERL programming language, MySQL database, Firefox Web browser, and Linux operating system almost certainly have played some role in making this Viewpoint readable on your screen. However, if you are within the ranks of the end users of information and learning technologies – faculty, the majority of students, an administrator who ultimately approves requests from your IT support unit – none of these names probably resonate with the familiarity of Windows XP, Microsoft Office, Eudora Mail, or Blackboard. What is there to know about open source? And is ignorance bliss or a potential missed opportunity to provide a more affordable and adaptable eLearning delivery system for your campus? We hope to answer the first question, and invite you into the debate on the second.
Open source software development typically is done by a loosely coupled, geographically and organizational diverse cadre of programmers. Josh Lerner and Jean Tirole have done a nice job describing the motivations of open source programmers and advocates. In general, open source development is done for stature in the open source community and increased job mobility, to solve interesting programming puzzles, to improve programs for the public good, and increasingly because computing organizations pay staff members to contribute to open source software projects.
It is important not to confuse payment for the right or “license” to use software with payment for support in using that software. Put another way, open source software is not free. In the commercial software sector, the purchase of license and support aspects appear to be one-and-the-same, and it is in the support options for open source software where much of the flexibility and benefit of the open source license model can be found. Just as there are numerous companies that, for a fee, provide patches, integration consultation, training, and on-call assistance for commercially licensed software, there are similar cadres of companies that provide the same support channels for open source software.
Also, and this is the most radically different option for your organization, you can use the rights granted to you under an open source license to inspect and modify the source code of the software through the establishment of your own support channels. Perhaps the biggest benefit of software used under an open source license is this flexibility gained by your organization in how it supports itself.
No matter which path your organization chooses – commercial or open source – those paths will require resources to fix and grow the software, respond to user needs, and keep the underlying hardware running. While it is an overgeneralization and necessitates a careful and comprehensive look at costs at any particular institution to be confident in the estimate, an open source software environment might have a total cost of obtaining and operating the software that is 80% of the total cost of acquiring and operating commercially licensed software. However, there are two other key cost estimates to consider in deriving total cost of ownership: the cost of exiting or migrating from a current software environment, and the cost of aggregating support costs across institutions so that ongoing costs of running the software can be shared. There can be substantial differences in the total cost of ownership between open source and commercially-licensed software if these last two cost categories weigh heavily in the comparison.
If you are an applications-oriented user more than an infrastructure user, the open source tools you may have heard discussed include such offerings as Sakai, Moodle, Open Source Portfolio, uPortal, and Fedora. Think of Sakai and Moodle as in the same universe of applications as Blackboard, Angel, and Desire2Learn; and Open Source Portfolio offering to meet needs similar to the ePortfolio functionality delivered within and LiveText software. uPortal provides an open software solution as a portal, and Fedora is an emerging open source platform to support and extend traditional library digital collection building and document management.
Of additional interest to the end user, Microsoft has announced a project to create a translator that permits Microsoft Office users to view and create documents in the OpenDocument Format. The OpenDocument Format is supported by the American Library Association, among others, and is the standard used by OpenOffice, a multiplatform, multilingual Office suite created as an Open Source project. Microsoft’s Brian Jones targets the end of 2006 for the Microsoft Word translator, with Microsoft Excel and Microsoft PowerPoint translators to be available in 2007. While there is some controversy regarding Microsoft’s rationale for building this translator plug-in, its existence will facilitate open source document creation and sharing.
A typical workflow within a college eLearning environment today might look something like this: A faculty member creates a Microsoft Word or Microsoft PowerPoint document as the basis for a student assignment. The faculty member uploads the document into the Blackboard Content Repository and makes it available to her students through the Blackboard Course Management System. Students create their own Microsoft Word documents and submit them to the faculty member, still within the Blackboard environment. The student also saves a copy of the assignment and submits it to his LiveText ePortfolio system. All of these interactions may be accessed from a university portal application, or they may each require a separate entry and authentication scheme.
Now consider an alternate workflow. The faculty member uses OpenOffice to author the assignment and saves it to what appears to be a network drive on the faculty’s desktop. In reality, the network drive is the faculty’s space in a Fedora-driven content repository – providing functionality such as version control and collaborative access. The Fedora system also serves as a universal document repository from which content is drawn into the Sakai course management system. As the student completes the assignment and uploads it into Sakai, the student’s work is automatically added to the Fedora repository, where it can be referenced from OSP (the ePortfolio system integrated within Sakai), or through collaboration tools used in conjunction with other students.
Many of the hand-offs within the components of this open source environment are governed by the MIT to support interoperability of these applications. This seamless eLearning environment is accessed using a single sign-on service, perhaps derived from the open source Internet2 Shibboleth Project. By the way, much of the infrastructure serving this distributed end-user community is centralized to capture the efficiencies of shared hardware and technical support staff. Campus personnel are able to work more closely with their end user communities, effectively filtering their requirements for the central staff to accommodate.(OKI) Open Service Interface Definition (OSIDs), a specification developed at
The Potential Drawbacks of Open Source
Open source software often isn’t well documented. Programmers develop for others in the programming community. Left to themselves, these programmers view documentation as an afterthought or a non-thought. As open source end-user applications begin to emerge, documentation, bug fixes, and training protocols are being developed and shared by other open source constituencies.
There are many examples where the user interface is not considered terribly important, and therefore is not very good. This too is a vestige of the “raw programming for other programmers” culture. Those who work from command line interfaces have less need, and by extension value less, the graphical user interface that most end users require. “U/I” is receiving more attention, particularly as accessibility and Section 508C concerns permeate software development.
Supporting open source programming is beyond the skill sets/desires of many campuses. Yes and no. Many campuses do not want to provide open source support from internal campus resources, but a number of commercial support providers are appearing on the scene. Since there is more than one option for support, a campus is not limited to having only one support provider available.
Enablers of Open Source
The Internet, and easy exchange of code and discussion about that code. Even though those who work in the open source environment are geographically distributed, a number of collaborative development tools (JIRA, Confluence, SourceForge) exist that facilitate distributed development.
Puzzle solving can be engaging/consuming, especially in a community context. Programmers share the universal human traits of ego and desire for recognition by their peers. These motivations translate into writing good code. Open source encourages attribution for work, perhaps more than commercial source development. Open source skill sets may provide more job mobility than proprietary skill sets, because transportable skill sets may be constrained by nondisclosure agreements with current employers.
Commercial firms seeking to avoid cross-dependencies of programming modules. Commercial programs built on other commercial programs cede some control of their own pricing and development paths. For example, Oracle might wish to encourage its clients to use Linux O/S rather than Sun Solaris to stabilize their own development environments.
Should You Bet Your Career on Open Source?
“Pretty to think so” closes Ernest Hemingway’s The Sun also Rises and is also the melancholic, slightly cynical response from those who view “tomorrow’s open source scenario” as unrealistic and ultimately unattainable. The skeptics have history as well as great literature on their side. There are many failed collaborations and fumbled interoperabilities to reference. Yet despite the lessons of literature and history, we have the disciplines of economics and sociology to suggest the time may have come where at least a hybrid model of shared, open source infrastructure may be attainable.
The economics of open source and shared services built on open source encourage evaluating open source options. Accountability in higher education (and K-12) is prominent in the public eye, and collectively open source may assist us in demonstrating that we are responsible stewards of fiscal resources. The sociology of open source has many organizations contributing and supporting one another, even if communication and collaboration patterns are still being invented.
What to Do:
- Join the debate. Read more and discuss more about open source. SUNY’s Patrick Masson offered some interesting statistics in a recent posting to a discussion board at a Sakai discussion site. He searched the Web sites at Indiana, MIT, Stanford, and Michigan for the co-occurrence of the phrases “open source” and “information technology.” He compared the co-occurrence results at these prominent open source institutions (IU-7.8%, MIT 65.35%, Stanford 15.3%, and Michigan (10.89%), to SUNY (1.89%). Try the same experiment at your institution. How healthy and broad is the open source discussion where you work? Without awareness, options can’t be debated.
- Establish a shared infrastructure pilot project within a cohort of institutions with something in common, with some reason to share insights or services. In Ohio, the Ohio Learning Network is sponsoring an open source testbed and more than 40 Ohio schools are evaluating a suite of open source tools. The Ohio Board of Regents has established a project called Collective Action (the open letter posted here provides some background on “Collective Action” and the concept of pooled risk) to aggregate and share open source experiences and to evaluate the viability of a shared open source (or hybrid) eLearning infrastructure.
- Recognize that open source not only represents new licensing and use opportunities, it also is ushering in new business models for software support. Open Source software separates the software development from the software support and customization environments. In contrast, proprietary software licenses typically require that the software developer also provide support and customization services. Red Hat Linux is one well-known example of a company that supports and customizes the Linux open source operating system. Talk to other schools that have contracted with a commercial provider of open source support. Consider pooling institutional resources to hire common staff to support open source on behalf of the group.
- Apply system thinking to system operating. If a community college and a four-year college that it feeds were to use interoperable software systems, and if licensing restrictions did not preclude shared, transferred, or jointly supported data and modules, how would it make your life, and the lives of your students, simpler?
In closing, we shared this article with someone who has “bet his career” on open source. As we’re sure you’ve figured by now, we’re not going to advise you whether to do so in your particular circumstances, but we thought we’d share his insightful answer with you:
“The value of open source is rarely that ‘you’ can inspect the source. It’s that the number of people who can is much larger than any one company, so the pool of support, and the labor to fix it, is potentially much larger than most companies short of IBM and Microsoft. Figuring out when an open source project reaches that tipping point is the hard part.
As far as betting one’s career, the question isn’t ‘open source?’ but one of evaluating any given project for its viability [whether commercial or open source]. That’s the challenge. [There are very many open source software offerings that are of poor quality and many commercial systems that have gone broke. However,] it’s a simple plain fact that mature open source is on par with proprietary code in just about any area short of really hard core stuff like relational database engines. There are certainly gaps like that, but they’re not common. So if you can only save 20% of the cost of supporting non-free software, ‘you’re not doing it right.’ That’s my philosophy. It’s the thing few organizations understand or are willing to accept because they don’t trust their own people to research and apply solutions without the mythical crutch of a vendor.”
Ready to place your bet?
Stephen R. Acker (firstname.lastname@example.org) is director, learning technologies research and innovation at The Ohio State University. Peter E. Murray (peter@OhioLINK.edu) is assistant director of Library Services and Multimedia Databases, OhioLINK. They would like to thank Scott Cantor, Ohio State University and Internet2, for “truth-checking” this article and for contributing substantially to its development.
- See Circular 61, United States Copyright Office, Copyright Registration for Computer Programs for background on copyright protection for software [↩]
- Nearly two thirds of all registered projects at ↩] [
- “GNU itself stands for GNU’s Not Unix, which isn’t very informative. What it essentially stands for is an ideology of free software. This is encapsulated under the GNU GPL: the GNU General Public License, which allows you to share and alter software under its aegis.” ↩] [