logo e d u f o r g e . o r g
Community Projects My Page
Summary Forums Wiki Tracker Tasks Documents Surveys News Files
     Advanced search
Log In | New Account | Suggestions Box

Do you agree? Let's hear from you!

Needed: an 'Educore' to Aid Collaboration

FREE SOFTWARE--come and get it! Opponents of the open-source-software movement (primarily commercial software vendors) refer to that siren song as the misleading allure of freely available software. They argue that you get what you pay for, and that free software cannot be relied on to run even a small business, much less a college or university.

In spite of those criticisms, many commercial and nonprofit organizations have found that they save substantial sums of money if they use widely supported, high-quality, free software like Linux, Apache, or MySQL instead of commercial alternatives. However, using free software may not make sense if it is designed for a narrow purpose, which may require expensive adaptations, or if it has a single developer, who may not provide adequate or long-term support.

If only the most widely used programs save money, are there other reasons for colleges and universities to adopt open source? And if so, what are the major impediments to doing so?

The desire to be independent of any single vendor is often cited as the primary motivation for adopting open-source alternatives. Many academic institutions are also concerned about predatory pricing, mergers and acquisitions that threaten the continued availability of critical software, desirable features that the vendor is unlikely to add, and the absence of standards that make integration with other software difficult or impossible.

As the costs of buying or creating software have grown, even the largest universities are seeking the significant economies of scale possible through the collaborative development of information technology for higher education. In addition the desire to harness the collective talents of people from many institutions to produce software that meets the particular needs of higher education is a strong justification for embracing open-source approaches.

The single biggest obstacle facing colleges and universities that want to use open source appears to be the uncertainty about future support for and improvements in the software. Many administrators and trustees simply cannot accept the idea of relying for maintenance and support on people with whom they have no contractual relationship.

THE SOLUTION that I propose for higher education's long-term software needs is the creation of a coordinating body, perhaps called Educore--a name reminiscent of Bellcore, the Baby Bells' cooperative designed to conduct research and development, and to set standards. Supported financially by a large number of colleges and universities, Educore would coordinate the development and maintenance of open source for the benefit of higher education.

To attract widespread support, Educore would offer software that included abundant features, adhered to standards, and could be enhanced by users. Educore would give universities the security they seek, but rarely find, in their relationships with corporate partners--who can raise prices and maintenance fees suddenly, or stop producing or supporting programs with little warning. Academic institutions have often had to augment corporations' proprietary code with expensive, customized modules, and they have rarely benefited from each other's efforts.

Is a coordinated approach to the development and maintenance of open-source software for higher education merely a pie in the sky? Several major projects that are currently under way will, I believe, help answer that question and ultimately determine the viability and value of such an endeavor. The two projects that best exemplify the potential of open source in higher education and that would, if they are successful, lead naturally to a broader effort are Chandler and Sakai.

Chandler's origins go back to 2003, when the Open Source Applications Foundation began working with the members of the Common Solutions Group to create software for higher education that was open source, based on standards, worked with other software, was applicable to institutions of different sizes, and was secure. Twenty-five institutions of higher education each contributed $50,000 over three years to the effort, agreeing that the software would be available to other colleges and universities, too. With additional funds from the Andrew W. Mellon Foundation, a total of $2.75-million was available for the project.

The resulting open-source software, called Chandler after the mystery writer Raymond Chandler, is intended to give users access to critical personal data, including calendars, e-mail, lists, documents, attachments, instant messaging, and address databases. It will feature sophisticated sharing of information based on easy-to-use networking either directly among users or via a server. Early releases of Chandler are already available, with the final release scheduled for the end of 2005.

Like Chandler but on an even grander scale, the $6.8-million Sakai Project will ultimately bring together as many as 200 colleges and universities to leverage the efforts of four core institutions--Indiana University, the Massachusetts Institute of Technology, the University of Michigan at Ann Arbor, and Stanford University--to develop a modular, integrated collection of open-source programs that most campuses could use. Named for a chef on a cable-television cooking show, Sakai also involves the Andrew W. Mellon Foundation, the William and Flora Hewlett Foundation, the uPortal Consortium, and the Open Knowledge Initiative.

The Sakai Project will incorporate the best features of each core institution's locally created software to produce a course-management system with all the tools that faculty members need to post course requirements, readings, and assignments; perform assessments on the Web; and make it possible for students to communicate with one another and with their professors online. Use of Sakai throughout higher education would result in significant collective savings, standardization of programs across institutions, and a successful model for the development of further software. The participation of a large number of institutions would help to ensure the software's maintenance, sustainability, and widespread use.

In February the Sakai Project created the Sakai Educational Partners' Program with a $300,000 grant from the William and Flora Hewlett Foundation. The program is designed to secure continuing financial support, with each partner institution agreeing to contribute $10,000 annually with a three-year commitment. The partners get access to the program's technical staff, new software code before its official release, workshops, and an online database of information. Almost 50 institutions have already joined, and the project expects to have more than 200 partners by July 2005, when the final version of the software is scheduled for release.

THE NEXT STEP is to ratchet up those models of collaboration by an order of magnitude, moving from a series of independent initiatives to an Educore that would coordinate, pay for, and assure the long-term support of a wide variety of open-source projects to benefit higher education.

The new organization might involve more than 1,000 colleges and universities from around the world. Each member institution would be asked to contribute between $5,000 and $25,000 per year, based on size--which would probably be less than they spend on most proprietary software packages. That would produce more than $10-million per year, enough to coordinate the development, packaging, delivery, and maintenance of many of the key academic and administrative software applications that higher education needs. Educore could use its money to aid multi-university efforts like Sakai or development by a nonacademic entity, as in the case of Chandler; to support small groups of developers at a single university; or to develop software itself.

Educore would consolidate existing efforts to develop software for personal-information management, learning-management systems, authorization and authentication, and so forth. It would relieve higher education of the high acquisition and maintenance costs associated with proprietary software. It would assure that all applications were open source and worked in the hardware and software environments commonly found in colleges and universities.

The outcome of projects like Sakai, Chandler, LionShare? (peer-to-peer software being developed at Penn State University), and OpenCourseWare? (MIT's initiative to distribute most of its course materials on the Internet) will indicate whether Educore is viable.

Even if all of those projects are successful, for Educore to work a large number of universities would have to agree to support it, and to share its software with nonmember institutions. Universities are likely to join if they want to be part of an overall effort that offers significant benefits for academe, if they want to participate in developing software or have access to early versions of programs, if their peer institutions belong, or if membership becomes prestigious.

Of course many questions will arise, including how priorities for software development will be set, what Educore's general governance should be, whether the organization should be part of a larger enterprise, and where it should be located. The business case for, and ultimately the success of, Educore will depend on our collective ability to produce high-quality programs that are capable of serving institutions with very different infrastructures and approaches to education.

Fortunately, as is increasingly evident from projects like Sakai and Chandler, institutions are interested in open-source software, its benefits are substantial, and the economics of collaborative work seem irresistible.

~~~~

By Ira Fuchs

Ira Fuchs is vice president for research in information technology at the Andrew W. Mellon Foundation.


 
    
© Eduforge.org 2005 Powered By: gForge | PhpWiki | Serendipity