There was a time when I was moving in both the worlds of the Sakai Collaborative Learning Environment and the Fedora Commons digital content repository. It seemed like a good idea to bring these two worlds together — Fedora as a content repository for Sakai learning objects. Back in 2006, I logged a ticket in Sakai’s tracker to see if anyone was interested. This morning I got notification that they are thinking of closing the ticket.

I’ve since moved away from both communities into other areas of interest, but felt one final duty of stewardship over this idea before it drifts out to sea. Perhaps integration between Sakai and Fedora Commons is already happening and this ticket is anachronistic. Perhaps this wasn’t such a good idea to begin with and it should die on the vine. Perhaps someone else will think this is a good idea and become the champion for it. At this point, though, my professional interests are elsewhere and I can’t carry this one forward.

Here is the text of the message:

Issue (View Online) Key: SAK-7833 Issue Type: Feature Request Status: Open Priority: Major Assignee: Unassigned Reporter: Peter Murray Operations  View all  View comments  View history

Fedora as Sakai’s Content Repository  Updated: 23-Feb-2010 06:32   Created: 27-Apr-2006 08:20   The following issue has been updated. Updater: David Horwitz Date: 23-Feb-2010 06:32 Comment: MAINT TEAM REVIEW: This feature request is currently unassigned and will be reviewed. In line with stated Jira practice [http://confluence.sakaiproject.org/display/MGT/Sakai+Jira+Guidelines] Feature requests that are not going to be implemented will be closed with a status of "wont fix". If you intend implementing this issue please ensure that its up to date and assigned correctly Project: Sakai Components: Content service (Pre-K1/2.6), Resources Affects Versions: 2.2.0, 2.2.1, 2.2.2, 2.3.0, 2.3.1  Description    Provide an alternative to the existing ContentHostingService interface that stores content in database tables, directories, and files with one that stores and retrieves content in a Fedora Digital Object Repository.

This started out as a comment to a posting by Chris Coppola, president and co-founder of rSmart Group. The comment got longer and threaded with yesterday’s posting about the nature of BioMed Central, so I moved it to this posting on DLTJ. For those in the library community who are not familiar with rSmart, it provides commercial support for the Sakai collaboration and learning environment and the Kuali administrative systems suite. rSmart is somewhat equivalent to Equinox Software and LibLime in the library automation arena.

Aligning Clashing Values Under Open Source

we should be careful not to over generalize. There are clashing values between some businesses and the education community. Blackboard might even be the poster child for values that clash. But there are businesses out there that operate with the same collegial cooperation, and share the values of the education community. Indeed some are part of the education community.

He’s right, and I would propose that what makes rSmart (and Equinox and LibLime and other similar companies) different is a commitment to open source principles. The values of the business and the values of the academic institution are more closely aligned when the outcome is a better piece of open source software for the business and the academic institution. As rSmart thrives, so does the underlying open source platforms — and here is the key — whether or not consumers of that underlying platform are direct customers of the commercial support entities.

Aligning Clashing Values Under Open Access

The text was modified to remove a link to http://www2.library.yale.edu/movabletype/scilib/archive/2007/08/library_drops_b_1.html on January 19th, 2011.

The text was modified to update a link from http://coppola.rsmart.com/node/32 to http://coppola.rsmart.com/2007/08/14/educational-patents-open-access-journals-and-clashing-values/ on January 20th, 2011.

This posting has two goals — first, to introduce DLTJ readers to the notion of “Educational Patents” or “edupatents” and provide an update on events of this week. Second, to frame the sometimes contentious interaction between academic institutions and supporting businesses as one of “clashing values.” The former serves as a cautionary tale within the wider scope of the latter.

Educational Patents

The end of last year was a very busy time in the world of edupatents. In early October 2006, the EDUCAUSE board issued a statement denouncing the lawsuit followed by events in December at the Sakai conference in Atlanta: Eben Moglen’s (of the Software Freedom Law Center) keynote speech on the dangers of edupatents [MP3] and a debate between Eben Moglen and Matthew Small (Blackboard’s chief council) on the merits of Blackboard’s case. (I highly recommend listening to both recordings.) All of this was followed by news earlier this year from the combined EDUCAUSE and Sakai boards of a negotiated non-aggression pact between Blackboard and the open source community.

Just this week the story got even more interesting. First, Desire2Learn reported on a major decision by the court in the Blackboard lawsuit: “Claim 1 is rendered invalid because of indefiniteness. Further, all dependent claims that rely on Claim 1 (in our case, Claims 2 through 35) are similarly invalid.” That leaves only Claims 36 through 44 in play. Second, Blackboard file a “preemptive” lawsuit against Turnitin (Internet-based plagiarism-detection service) that seeks to prevent Turnitin’s parent company iParadigms from suing Blackboard over potential claims that Blackboard may have violated iParadigms’ patents (a story from Chronicle of Higher Education [subscription required], Michael Feldstein’s analysis and iParadigms’ view).

How does this apply to academic libraries? In describing the Blackboard versus Desire2Learn lawsuit, Al Essa proposes: “In addition to the core technologies associated with a [Virtual Learning Environment], the Blackboard patent potentially covers any infrastructure and integration elements when used in the context of course delivery.” Could that cover our online course reserve systems? Or our portals for delivering electronic materials to online classroom environments? It may apply directly to our services.

Open Access Journals

[20070812T1930 update: Please note that the first link in the last sentence points to a posting by Bill Hooker in his Open Reading Frame blog about the economics of BMC's publishing model. Bill is decidedly pro-Open Access -- as am I -- and we have a running discussion in the commentary of this posting on DLTJ.]

Clashing Values

So here’s the point: I propose that it is further evidence that we need to take control of our destiny. Not to spell out a doom-and-gloom scenario, but there may be a “perfect storm” brewing in the consolidation of the integrated library system vendors, the entrance of venture capital into the ILS market place (and the corresponding expectations for profitability), and the rise of open source options to the traditional vendor-supplied ILS. None of the ILS vendors appear to be striking out with lawsuits like Blackboard has done. A spirited discussion could be had on whether the ILS vendors are pricing their products in an unrealistic way (as with the BioMed Central example). In any case, it would be in the best interest of the students and faculty that we represent to be mindful of these clashing values. While it is important to be respectful of the traditional values of the business community with whom we interact, it is even more important to act in a manner consistent with the values of our traditional academic community with which we are a part.

The text was modified to update a link from http://blackboard.com/company/patentFAQ.htm to http://www.blackboard.com/About-Bb/Patents/Frequently-Asked-Questions.aspx on January 19th, 2011.

The text was modified to remove a link to http://issues.sakaiproject.org/confluence/download/attachments/34226/2006_12_06_Keynote_Eben_Moglen.mp3 on January 19th, 2011.

The text was modified to update a link from http://chronicle.com/daily/2007/08/2007081005n.htm to http://chronicle.com/article/In-Preemptive-Action/122899/ on January 19th, 2011.

The text was modified to remove a link to http://www2.library.yale.edu/movabletype/scilib/archive/2007/08/library_drops_b_1.html on January 19th, 2011.

This could easily go in the “Disruption in Libraries” category of DLTJ, but it is a disruption of a different sort. Are you making contingency plans to continue library services in the event a Bird Flu pandemic (or an event of similar sort) happens? A recent posting on the Sakai developer’s mailing list prompted the thought. Sakai is an open source collaboration and learning environment that is typically used for electronic courses. John Leasia of the University of Michigan wrote:

We here at UMich are doing some contingency planning in the event we are hit with a Bird Flu epidemic. We have heard some institutions are planning on just shutting down. Some like UM intend to stay open and move from our predominately in class instruction to all online. We are currently planning what needs to be done now (tutorials, tool enhancements, new tools, adoption of existing tools not yet in production here, infrastructure scaling, etc.) [to enhance the local Sakai installation] in order to be ready should an epidemic strike.

Are there others out there in the same situation? How about some of us holding a joint Discussion session at Amsterdam [the location of the next Sakai users conference]? We could each provide a brief overview of our planning thus far and then open it up to see what everyone is doing, raise issues/questions we haven’t thought of, perhaps start coordination of development/training/doc that might be necessary?

Are there other institutions out there thinking about the same thing? Has the library been asked to participate in the contingency planning? Are you undergoing your own planning?

This is a summary of a presentation by James L. Hilton, Vice President and CIO of University of Virginia, at the opening keynote session of Open Repositories 2007. I tried to capture the esessence of his presentation, and omissions, contradictions, and inaccuracies in this summary are likely mine and not that of the presenter.

Setting the stage

This is a moment in which institutions may be willing to invest in open source development in a systematic way (as opposed to what could currently be characterized as an ad hoc fashion) driven by these factors:

• Fear. Prior to Oracle’s hostile take-over of PeopleSoft, the conventional wisdom of universities was that they needed to buy their core enterprise applications rather than build them. In doing so, they sought the comfort of buying the security of a leading platform. Oracle’s actions diminished that comfort level. Blackboard acquisition of WebCT and lawsuit against a competitor does not help either.
• Disillusionment and ERP fatigue. What was largely thought to be an outsourced project was found to be an endless upgrade cycle. Organizations need to build entire support units to handle the upgrades for large ERP systems rather than supporting the needs of the users.
• Incredulity — we’re supposed to do what? The application of technology typically has a disruptive impact (cannot predict the end), the stakes are incredibly high (higher education and/or research could be lost in a decade), it tends to be expensive, and the most common survival strategy is to seed many expensive experiments in the hopes that one will be in the right place at the time the transition needs to happen. The massive investment anticipated for technology to support academic computing (libraries, high-performance clusters, etc) will pale in comparison to the investment in administrative computing.
• Rising tide of collaboration. This is a realization that the only way to succeed is through collaboration. To paraphrase Hilton, “In the new order it will be picking the right collaborative partners where the new competitive advantage will come from.”

Distinctions

Hilton offered these definitions and contrasts as a way to frame the rest of his discussion. First was Open or “free” software. Free as in beer, or free as in “adopt a puppy.” The software comes with the ability to do with as you want with the code, not just the ability to use the code. They he defined the term License as a contract — what ever you agree to you are bound to; you cannot use copyright law to protect you. The rules and conditions that are applied to the software do matter.

Lastly, he talked about Copyleft or “viral” licensing. There are different interpretations of “open” in open source. “Copyleft” has come to mean that code should be freely available to be used and modified, and it should never by locked up. GPL is an example. This is often called “viral” because if you include software with this license in any other work that is released, the additional software must be released under the same license. This is seen by some as valuable because it prevents open source from being encircled by proprietary code. Copyleft is contrasted with an “open/open” license — you can do whatever you want to do with a code under this license. An “open/open” license places no restrictions on what users do with code in derivative software packages.

Case Study — Michigan’s Sakai Sojourn

Hilton briefly described why UMich went down the Sakai path in 2001-2002:

• Legacy system with no positive trajectory forward. It could never be released into open source; all of the development would have to be carried on UMich’s shoulders forever.
• Saw market consolidation in CMS. This was mostly evident in the commercial sector with Blackboard and WebCT being the dominant choices. They had concerns about the cost of licenses in this environment down the road.
• Saw the potential of tapping the institution’s core competencies and starting a virtuous cycle of development, teaching and research. Or, put another way, they didn’t want core competencies in teaching and research held hostage to a commercial development cycle.
• Strategic desire to blur the distinction between the laboratory/classroom and between knowledge creation/digestion. They realized that the functions of a research support tool and a course support tool were pretty much the same under different skins, and they sought to blur that distinction even more.
• NRC report and the need for collaboration. UMich was willing to fund the project two years internally but knew after that need to find collaborative partners by the fifth year in order to be declared a success.
• A moment of time opportunity that synchronized the development process of several partners with funding provided by the Mellon Foundation.

There were also specific goals for the Sakai project. The new system had to replicate the functionality of existing course and research collaboration environments. They also wanted experience in finding partners willing to collaborate. Hilton said, “Sakai was/is at least as interest from a collaboration perspective as it is from the technology perspective.” Bringing together disparate organizations with different beliefs on how things should be done is a challenge. Additionally, they wanted to get better as an institution at discerning open source winners; it shouldn’t be like a lottery. Lastly, they wanted to implement software parts that were not built at UMich. Each partner institutions committed to implementing the same thing even if wasn’t built at that institution. This is tough to do, but they knew they needed to do it for their own good in the long run.

What happened? Not only did the original partners show up, but the community came, too. Even more interesting was that the community was formed with dues-paying members — even in a world where the software is free. It became a vibrant community, too, with a conference every six months. Sakai was released under an open-open license model, and corporate partners showed up as well (selling support services, or hosting services, or hardware for the software). The software did grow up and left its home; a separate foundation now holds the intellectual property of the code (originally partners assigned copyright to UMich). They also positioned Sakai to be a creditable threat to the commercial entities in order to force them to the standards table.

Takeaway lessons that generalize to open source development

First, the benefits of open source development.

• destiny control (but only when you really need to drive). having the control is not always a good thing. Is it worth the effort? Is the project core to the institution’s mission? (Does it directly support scholarship and teaching?)
• builds community and camaraderie (in the case of Sakai, both locally at UMich and internationally)
• unbundles software ownership and its support. inspires more competition in the implementation and support space.
• community source provides institutions an opportunity to leverage links between open source, open access and culture of the academy/wider world (a.k.a. put up or shut up)

Then, the challenges of open source development.

• Guaranteeing clean code (IP) is hard (read as “impossible”). A certain amount of faith about the code they get and there needs to be consideration for mitigating risks.
• Figuring out who is authorized to license institutionally-owned code is challenging and then you have to convince them to give it away. No one in the institution typically has been appointed or given the authority to release code. One of the things that the sakai licensing discussions highlighted was institutional differences in requirements and aesthetics.
• Patent quagmire always looming. How do you know your software is not infringing? How do you make sure you don’t inadvertently give away all institution patents? Be careful when looking at licenses from an institutional perspective versus an individual perspective.
• There is also the inevitable lawsuit risk. Or, as your counsel might say to you, “Let me get this straight, we can get sued but there’s no one we can sue.”

Then, some discoveries that they made along the way.

• An open source project not a silver bullet. The commitment to build rather than buy must align with institutional priorities and competencies; it is not right for every project/application.
• Licensing does matter; it is a contract: whatever you stick in its rules is what sticks. There are probably have too many open source license options and some sort of standardization is needed. Also keep in mind that if you release something under an open/open license, you can’t include any copyleft components.
• Communities don’t just happen, they require: specific shared purpose (when visions vary, or when they change, collaborations struggle); and governance (e.g., separate board with dedicated developers sitting between institutions). Cooperation (“I won’t hurt you if you don’t hurt me”) is not collaboration.
• Open (community) source requires real project discipline. “It is as spontaneous as a shuttle launch.” Along the way one needs to learn to balance pragmatics and ideals. One also needs to learn to trust your partners. “It really requires learning to let go.” Letting go, and having the community make the decisions, may be the quickest path to efficiency.

Reflection on open/community source for repositories

Repositories are at the center of everything at the institution. It connects with the library, with the presses/scholarly publishing operation, with classroom teaching, with the laboratory, and with the world. It is a core piece of of infrastructure for the university of the 21st century. As institutions, we need to make sustaining investments in our repositories.

Hilton sees three different approaches to “community” in the existing projects:

• dspace: community of user/developers. The come together to talk about what they want to do, write code, and support each other. Clearly there are enthusiastic users as developers.
• eprints: appears as like a vendor talking with customers wanting the community help shape the direction.
• fedora: in transition from a combination of the previous two models moving towards a Sakia-like model. it will require institutions to make commitments to it.

In the end, Hilton asked some thought-provoking questions. Is now the time for institutional investment in open/community source? Will a coherent community (or communities) emerge in ways that are sustainable? — is there a shared vision?

The text was modified to update a link from http://www.virginia.edu/vpcio/bio.html to http://www.virginia.edu/vpcio/biography.html on January 19th, 2011.

Earlier this year, I was on a quest to hook a FEDORA content repository into the Sakai collaboration and learning environment. What looked at first to be a fairly easy integration turned out to be rather complicated and I set the project aside for another time. Today brings word from Ian Boston of a JSR-170 implementation in Sakai:

During the Summer of 2006, I did a JSR-170 Implementation of ContentHostingService as a prototype against the then Trunk 2.2 ContentHostingService. The implementation took the ContentHostingService API and re-implemented it using JSR-170 under the covers. It was done in in such a way as to allow JSR-170 clients (eg WebDAV implementations) to use the JSR-170 API directly and still obey the Sakai AuthZ implementation.

JSR-170 – Project: Resources – Sakai Confluence

JSR 170, as you might recall, is the “specification for a Java platform API for accessing content repositories in a uniform manner.” ¹ What makes this implementation most interesting, I think, is Ian’s last sentence — using a WebDAV implementation to speak directly to the JSR-170 content repository while taking into account the AuthZ settings in Sakai.

Now we need a JSR-170 implementation on top of FEDORA to complete the pairing. We’d want Sakai’s AuthZ settings to be reflected in FEDORA’s XACML rules, of course, the the mind boggles a bit about how to get this done, but hopefully we can get back to it again soon and see if we can make it work.

The text was modified to remove a link to http://issues.sakaiproject.org/confluence/x/ikE on January 13th, 2011.

The text was modified to update a link from http://www.tfd.co.uk/blogs/sakaiblog/ to http://blog.tfd.co.uk/ on January 19th, 2011.

Footnotes

1. “JSR-170,” Wikipedia, The Free Encyclopedia, http://en.wikipedia.org/wiki/Content_repository_API_for_Java?oldid=84044565 (accessed November 8, 2006)

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.

First, a little more information about what open source is, and what open source is not. Software of any variety is protected under copyright law as a creative work ¹. In the case of commercially produced software, it is a license to use the copyrighted software, not the software itself, which is purchased through a traditional requisition process. This subtle distinction is important in understanding the role of open source licensing in the software marketplace. The acquisition of open source software is not based on a currency transaction for the license to use a piece of software. What is accepted, rather, is an agreement on the terms of use, modification, and redistribution of that software.

The most popular open source license ² is the GNU ³ GPL (General Public License). It grants the recipient permission to use the software without licensing fees and with permission to modify it, but requires the licensee to agree not to impose non-GPL terms on others that use enhancements created by the recipient. Various other open source licenses are certified by the Open Source Initiative (OSI) – “a non-profit corporation dedicated to managing and promoting the Open Source Definition for the good of the community” with varying degrees of restrictiveness and/or terms of use, yet all still under the general umbrella of “open source.”

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 Epsilen 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.

Current Scenario

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.

Tomorrow’s Scenario?

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 Open Knowledge Initiative (OKI) Open Service Interface Definition (OSIDs), a specification developed at 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.

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 (acker.1@osu.edu) 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.

The text was modified to remove a link to http://freshmeat.net/stats/#license on November 17th, 2010.

The text was modified to remove a link to http://www.linux.adopto-computers.com/glossary.html on December 31st, 2010.

Footnotes

1. See Circular 61, United States Copyright Office, Copyright Registration for Computer Programs for background on copyright protection for software
2. Nearly two thirds of all registered projects at http://freshmeat.net/stats/#license
3. “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.” www.linux.adopto-computers.com/glossary.html

What happens when you mix two Mellon-funded projects? Perhaps a nice bit of what they call synergy. The thinking goes something like this…

Sakai

Written in the Java language for a servlet container, it is an example of some of the best thinking and work in the creation of a course management system (CMS) or a learning management system (LMS) [that plus "CLE" -- how many acronyms do we need?] in the open source arena. It is truly an example of how higher education can take command of its destiny.

Fedora

Also written in Java to run in a servlet container, it is the best of the basic research of the general characteristics of a digital object implemented in an easily approachable (and again — open source) application.

Mix Together with a Glob of Glue

The methods for the Sakai Entity interface are:

• getId: Access the id of the entity.
• getProperties: Access the entity’s properties.
• getReference: Access the internal reference which can be used to access the entity from within the system.
• getReference: Access the alternate internal reference which can be used to access the entity from within the system.
• getUrl: Access the URL which can be used to access the entity.
• getUrl: Access the alternate URL which can be used to access the entity.
• toXml: Serialize the entity into XML, adding an element to the doc under the top of the stack element.

If this pans out, it should be relatively straight forward to swap out Sakai’s built-in repository infrastructure with that of Fedora. At the very least we’ll need some new content models and disseminators. So we’d have some more work to do on the Fedora end of the equation (and the Sakai end is a bit of an unknown to us at the moment), but on the surface it seems possible.

Footnotes

1. See http://sakaiproject.org/index.php?option=com_content&task=view&id=103&Itemid=208
2. See http://fedora.info/

Word of this Fedora-based image collection tool comes from the Sakai Library & Repositiories discussion group [Sakai Collab account required].

Project Name & Description (Short)

bSpace Images Version 1.0
The initial version of bSpace Images will focus on personal collections and provide “baseline” functionality found in existing tools like Course Gallery, ARTstor, Luna Insight, Portfolio, and Spiro. Through a user centered design process, bSpace Images features will be driven by faculty observations and interviews. Unlike the other campus offerings, its interface design will be based on the faculty’s real needs.

Version 1.0 will consist of 4 phases: “Personal Collection Migration”; “Find, Browse, Organize Collection”; “Course/Lecture Galleries”; “Image Ingest from Personal Computer”. This diagram provides a list of proposed features for each phase.

They have a nice vision for the integration of a library repository with a collaboration and learning environment. This is definitely something we should watch and see if portions can be applied to the DRC project.