Figure 6.1. 

Pat Masson currently serves as the Chief Information Officer for New York College of Technology at Delhi. As CIO, Pat provides oversight, leadership and vision for the college’s Campus Information Services including enterprise applications, technical centers and labs, server/systems administration, network & telecommunications, online/distance learning as well as user support such as help desk services.

Previous to his appointment at Delhi, Pat worked for The State University of New York System Administration as the Director of Technology for Learning Environments, and was responsible for leading technology design, development and deployment of system-wide projects including SUNY’s e-learning platform, SLN, serving over 110,000+ enrollments, 5000+ courses and over 3,500+ faculty annually. Prior to joining SUNY, Pat was Director of the UCLA Media Lab.

I do not know where the debate now resides regarding the adoption of Open Source Software (OSS), that is, if it is now a business or cultural issue. But I am sure that while it may have once been a debate within IT, it is not now. Much of the technical debate about functionality, quality, support, etc. now seems tired and even trivial. Are we still questioning the feasibility of community development and the viability of OSS? I guess so, I’m writing this, and you are reading it…

Based on Open Source’s adoption among commercial software providers, OSS would appear to be an accepted and proven approach. According to a 2005 report by Optaros, The Growth of Open Source Software in Organizations, “Some 87% of the 512 companies we surveyed are using open source software. Bigger companies are more likely to be open source users: all of the 156 companies with at least $50million in annual revenue were using open source.”

Figure 6.2. 

Figure 6.3. 

Many of academic computing’s most prominent vendors not only rely on open source projects, but contribute to them as well, including: IBM (Eclipse, Sakai, SUSE Linux), Oracle (Berkeley’s DB, Eclipse, Fusion Middleware, jDeveloper, Unbreakable Linux, PHP, Sakai) Novell (Apache, Eclipse, Jboss, Linux Kernel, Mozilla, MySQL, openLDAP, OpenOffice, openSUSE, Perl, PHP, PostgreSQL, Samba, Tomcat, Xen) SUN Microsystems (GNU/Linux, Java, OpenOffice, OpenSolaris, Sakai, uPortal), Sungard Higher Education (Sakai, uPortal) and Unicon (Sakai, uPortal, Zimbra). There are some very telling examples of companies who have integrated Open Source into their businesses; those who simply support open source tools (too many to name), those who have released a previously proprietary code base into the public domain (e.g. SUN Microsystems’ Java programming language), and most telling of the acceptance of open source and community development within technology markets, those who have actually integrated open source tools into their commercial product lines (e.g. SunGard’s use of uPortal within Luminis III)–hardly the move to make if you consider open source products to be poor in quality or unreliable in development.

And yet there is another area, often overlooked, where OSS has proved valuable to commercial developers. In addition to the actual software, the movement has also helped redefine the software development life cycle, that is, how applications are designed, developed and deployed. “Community Development” has become a standard practice capitalizing on Linus’ Law described by Eric Raymond in The Cathedral and The Bazaar as, “given enough eyeballs, all bugs are shallow.” Many of the techniques associated with “extreme programming” and “agile development,” that are common today in software development, co-evolved with open source and free software projects as they adopted Bazaar-style open development models: pair-programming, user-developers, short development cycles, iteration, etc. Many of today’s commercial providers producing proprietary software have adopted “open” development methods. David Treadwell, corporate vice president of the .Net Developer Platform group at Microsoft, said in a November 2005 interview with eWeek that Microsoft encourages agile methodologies such as Scrum and extreme programming, “the concept where you might have two people working on a given piece of code and the idea is that two minds are better than one. Because you can find problems faster.” In another example, Common Services Architecture “represents a new paradigm for collaborative software development within SunGard. It’s a collaborative development process—a way of creating software that allows SunGard product development teams around the world to share, contribute to, and leverage, each other’s work.”

So there seems to be a clear indication from those outside academic computing—in fact those that we within academic computing are paying for services—that the technical debate regarding open source is over. However, the decision-makers in academics, do not seem as willing to accept the same, and appear to be taking up the debate all over again, albeit with different arguments.

Figure 6.4. 

Remember Madge, the manicurist who used Palmolive as a moisturizer? I think many within academic environments are shocked when they find out how dependent their operations are on open source tools, just as Madge’s clients where when they found out that they where soaking in dish soap. The analogy works because an expert found a tool that works, and the client shouldn’t care as long as the requirements are met and the outcomes are acceptable, but I’ve seen the same reaction from administrators as that displayed by Madge’s clients, shock, fear and pullback.

It’s obvious that technology is playing a greater and greater role throughout the campus. Many traditional business practices are being supported or even replaced by “technology.” There are the obvious examples; how many memos make up inner-office communications versus email, how much teaching and learning is now delivered with learning management systems, how many students enroll and register with student information services on-line, etc. These, as I said, are the obvious ones. However on my desk right now I have software proposals for less obvious systems; a housing management system that allows students to select rooms, roommates, meal plans, etc. submitted by Residence Life, an alumni analytics package that provides the Alumni Office with prospective contributors, veterinary management software for our Vet. Tech. program to help manage the care of the department’s animals, a fuel management system requested by campus Facilities for dispensing and monitoring fuel, a SoIP, or security over IP, application for the University Police, and many others. To support these systems, I may deploy them on various open source tools within my department, Campus Information Systems. Do the deans, directors and decision-makers know this? Would the fact that we may use the Linux version vs. the Windows version affect their decision making in identifying the right “solution” for their business case? Let’s really add some complexity, what if we installed the Windows version on a virtual server? Who makes these decisions regarding the use of open source?

I think one of the often overlooked parts of open source adoption, even ridiculed, by those in technology who have accepted OSS, is governance: not pertaining to an open source project, but rather the campus’ or institution’s management of “enterprise” systems and services. As institutions begin to explore open source projects and the communities which support them, they are likely to experience push-back from those new, unfamiliar, concerned, reluctant or even opposed to—not the products’ functionality, features or usability—but open source software itself. While concern may have come from technologists in the past, today, in my experience, resistance comes from the departments IT supports. Many working within IT are quick to write off those who “don’t get it” and simply continue working with OSS without the official blessing of their institution, confident that their activities will inevitably become operational as more and more users come on line (sort of a bottom-up, or under-the-radar approach) with departments eventually adopting the ubiquitous system(s).

This approach to IT governance is based on how open source tools have traditionally been deployed within the campus’ computing environment, and could be called the “stack approach.” This is based on the growth open source software has seen within the campus data center, “low in the software stack,” focused on operating systems, server software, development tools, databases, etc. As campuses become more familiar and comfortable with (dependent on?) OSS in these utilities, presumably, the door will open for systems such as email, content/learning management, business and finance, even fuel management systems: those services deemed mission critical by campus decision makers as “enterprise applications.”

And in fact, OSS has enjoyed significant adoption on campuses within the data center, the paradox is, few know it… especially those within the campus’ administration. As an academic CIO, I cannot recall many conversations I have had with my peers (other CIO’s, CTO’s, Directors of IT) or colleagues (Provosts, Deans, Administrative Directors) regarding utilities running low on the software stack such as server operating systems (Linux, Unix, Windows) web servers (Apache, IIS, iPlanet, SunOne, Zues, etc.), application servers (BEA, OAS, Tomcat, etc.), mail servers (Exchange, Postfix, SendMail, SquirrelMail, etc.), programming languages (Java, .NET, Perl, PHP, etc.) or, Integrated Development Environments (Eclipse, JDeveloper, WebShere, etc.). These are considered operational by my peers and insignificant by my colleagues. Interestingly, I have had countless debates regarding; desktop operating systems (Linux flavors, Macs and Windows), email clients (Domino Mail, Eudora, Outlook, etc.), Learning Management Systems (Angel, Blackboard, Moodle, Sakai, WebCT, etc.), Student Information Systems (Banner, Datatel, Kuali, PeopleSoft, etc.) and other “ERP” systems with, not my peers, but with my colleagues. CIO’s see these applications—and the decision to use them—within the realm of the campus departments, and so do the Provosts, Deans, Directors of HR, Finance, Enrollment, Alumni, etc. The now tired arguments that may have prompted technology folks to investigate open source—code quality, security, integration, customization, support, etc.—simply may not be applicable, important or even understood by those in other campus business units assessing their software needs against specific business operations, because these tools (and the values of OSS) operate behind the scenery. I would imagine that those reading this, care more about the content and discussion that may result within the forum, than the fact that it is presented with WordPress hosted on AIX and delivered via Apache.

In 2006 I presented findings on the deployment, and the opinions of administrators, of OSS within The State University of New York’s 64 campuses. The statistics, provided by Netcraft, identified which operating systems and server software where deployed on the SUNY campuses’ publicly accessible servers including email, ftp, media, web and others: all of which could be considered “low on the software stack.” The results indicated that while SUNY deployments of OSS was generally lower than global deployments (again provided by Netcraft), it was growing within the campuses’ data centers. For example, specifically to web server software, global deployment of Apache peaked at 70% with SUNY at 63% in 2005. SUNY also saw steady growth in Linux distributions running on various server types, rising from 7% in 2000 to 27% in 2006. However, these “adoption rates” measured applications transparent to end-users: web-server software and the operating systems they ride on. How many of the folks governing online education and debating Moodle are also debating the LAMP stack?

The insignificance of OSS adoption within the data center as an influence on more visible applications became evident to me when, as part of my research, I surveyed campus administrators. Respondents came from a variety of fields, including technology providers (CIO’s, IT staff, etc.) and end-users (faculty, non-IT administrators, etc.), and a clear division was evident. Open source software appeared to be a credible option within the data center for technical services but apparently not for systems that end-users touched. One respondent attested, “[my campus] seldom if ever adopts open source software.” However the figures provided by Netcraft indicated that all of that campus’ servers ran Linux and 23 of the 27 servers ran Apache. In fact, they where “soaking in it.”

This raises an interesting issue: how aware are campus administrators, who may be working with commercial providers such as SunGard’s Banner student information system and their portal Luminis, that they are actually relying on OSS? Is the confidence derived from a commercial provider (SunGard) diminished by the fact that Luminis is built upon an open source project, uPortal? Or availability for the entire suite of student services may be dependent on OSS within the campus data center? If so, shouldn’t Student Affairs, Enrollment, Finance, The Alumni Foundation, etc. be part of the governance (decision-making) for their complete “solution” from the SIS all the way down the software stack, and not just those applications they work directly with? Unless they are, the “stack approach” plays no part in the adoption of open source on campuses.

Figure 6.5. 

There is a rather cynical term, derived from Arthur C. Clarke’s above statement, and used by software developers to describe the unappreciated effort and technologies it takes to support user requirements: “automagic.” As those in software development can attest, end-users just want it to work and generally do not care about how that’s accomplished. Interestingly, one could argue, that the success of open source, as a development method, is due to just this sentiment: If the users don’t care about, or even understand, the technologies that deliver functionality, then let’s use those that provide us the easiest environment for deployment, open source.

Working in this “just make it work” environment, where more and more folks want more and more things to work, it’s understandable that the tenets of Free and Open Source Software would become standard operating practices within IT departments. For example, the ability to run software for any purpose allows the scope of services to expand, unhindered by licensing. This is a great resource as you deploy more instances of Linux through out the data center to support that growing set of departmental systems (Remember the fuel, housing and veterinary management systems?). Additionally, the ability to study how the software works and adapt it to an institution’s needs, provides for rapid development and quality assurance. These technical benefits have been the basis for those advocating the use of OSS. However, in my opinion, as long as open source is addressed as a technology issue it will never move into the status of commercial software. Consider a common topic on campuses today, Learning Management Systems. Should faculty be debating .NET, PHP and Java, or, SQL Server, MySQL and Oracle, or, Windows, Linux and Solaris, or, the waterfall method, Spiral techniques and eXtreme Programming, or, Angel, Moodle and Blackboard? That’s the goal, a debate over an application’s features, not a technology debate.

Figure 6.6. 

At a recent technology conference I was working away on my computer at lunch when the fellow next to me asked about my laptop, or more specifically my operating system’s desktop. Apparently he had noticed me rolling the 3D desktop, or “cube.” I explained that I was running SUSE Linux and that the 3D effects (Xgl) where all part of the operating system. In fact, this was not the first time someone had noticed and asked about the GUI and I expected this to be the beginning of a nice lunch time discussion (and a welcome distraction from my email). However the conversation faltered as Linux was quickly dismissed as “too complicated for average users,” something only “geeks” could use and support (yes, I guess he called me a geek). I continued on with the demo highlighting more of the graphics tools, searching tools, OpenOffice, the GNU tools like Gimp, etc. I showed him YaST and the Software Updater that installs patches, updates, etc. We talked about distributed networking and managing remote desktops. All of these were features, not technology. He was definitely impressed, SUSE was cool, SUSE was powerful, SUSE offered a lot of functionality and tools, but SUSE was Linux, and Linux was open source. So while it was OK for geeks, it was not very practical for business’ every day users, citing the usual technology related concerns about OSS; support (“you can’t call the guy in the basement who wrote it when it breaks”), quality (“how good can it be if it’s free and built by a guy in a basement?”), security (“if anyone can get into the code, then we could get ‘hacked’!”), etc.

I tried to respond by mentioning that not only can support be obtained by Novell, but even Microsoft supports SUSE Linux. I let him know that SUSE would run on his existing Microsoft network. I opened an Microsoft Excel document in OpenOffice Calc. However we quickly devolved into that same old tired debate. Although SUSE Linux provided all of his functional needs and met his usability requirements, we never got past the technical and into the operational.

Based on this I decided to try a little, utterly unscientific, experiment. A little later, when another person asked about my machine—admittedly I was flashing everyone who walked by with spinning desktops, wavy and transparent windows and tiled applications—I informed my subject that he was looking at a pre-release of Windows Vista. Our conversation immediately focused on “Vista’s” new features (the same ones I had shown the previous fellow), but this time it was all about usability and functionality. We never discussed how valuable his support from Microsoft was (I wonder how many tickets his institution has opened?), we never discussed how good the actual operating systems was (did it crash, was it buggy?), we never discussed security (perhaps his campus has never been the victim of a virus?) and we never discussed upgrade costs (I assume it was something he just was resigned to absorb). What were apparently barriers to open source adoption, were accepted as the cost of doing business for proprietary software. The lesson here for me was, “why even bring open source up?”

I suspect he knew what personal computing was on his campus, and while he did not know any of the technical issues involved with deploying and administering Vista, he knew the IT staff on his campus would have to make it happen, automagicaly!

If this person happened to be a decision maker on campus, SUSE as a desktop operating system would be dismissed because of open source issues (apples), not issues related to the actual functionality and usability (oranges). I would ask, does your Student Services or the Alumni Office really care if their business systems are running on AIX, Linux, OpenSolaris, Unix or Windows? I would wager no, they really only care that they can enroll students, assess fees and contact students and alumni. So, why then, would the office staff care if they where running SLED, OSX or Vista if all they really want to do is manage spreadsheets, write emails, store files, print and browse the web? They only would if OSS proponents bring it up. Enterprise level OSS is mature enough that it should be assessed just as commercial software is, based on business needs, functionality, features and usability.

So let’s embrace the automagic! Let’s let our colleagues live in peace, they don’t care about the technology issues low in the software stack (OS, servers, databases), they just want their applications up and running. So they shouldn’t care about the technology issues with the applications they can touch (LMS’s, SIS’s, desktop OS’s), they just want their applications up and running. To turn things around, I don’t really care if my campus uses Angel, Blackboard, Desire2Learn, Moodle, Sakai or nothing! That’s the on-line learning folks decision, and my job as CIO should be to make it work. And, I hope the faculty don’t care if we run OpenVM, Linux, Apache or MySQL, that’s how I’ll make their applications work, automagicaly.

Figure 6.7. 

Often in an effort to show added value, proponents for an open source application will include the benefits of open source development, for example, the ability to customize the application for campus-specific needs. This was just the case when I attended the recent NERCOMP/EDUCAUSE Conference and sat in on a presentation discussing a campus’ recent migration from Blackboard to Moodle. The presentation started off with, what I feel where several salient issues; why they felt it was time to re-evaluate their on-line teaching and learning tools, how they identified and evaluated the various offerings (feature set, licensing, etc.) and, migration and training issues. These topics where all specifically related to their department’s business practices and campus/faculty/student needs in on-line education. Unfortunately this was only half of the hour-long presentation. The second half was devoted to technical issues and presented by a PHP developer who was introduced as, “someone you really needed to have if you are going to run an open source LMS.” The topics discussed were; setting up a server (both hardware and software), downloading and installing Moodle and MySQL, development tools, working with the Moodle community in development and finding support, and even examples of both their customizations and supporting PHP code.

Why would these issues be of concern for faculty, instructional technologists and others evaluating the functionality and usability of learning management systems? If this had been a presentation on migrating to Angel from Blackboard, would the second half of the presentation be seen as important, even relevant, with issues like; how to set up IIS, SQL Server, using Visual Studio, Nuggets development and .NET? I doubt it. I suspect most in the crowd would have assumed that their campus’ IT department would just set it up and support it.

Like customization, collaboration is also frequently cited as a reason to adopt OSS. The idea is that because OSS is developed in an open community where achievements are shared, end-users can leverage this development to increase functionality. And this is true. Scrolling through many open source project forums yields plenty of how to’s, fixes and patches, tips and tricks, etc. Last year, a debate arose about who the Sakai community was and who it best served. I added to the debate within the Sakai discussions:

I was essentially asking, how valuable is the community and collaboration for end-users? In order to find out I researched the discussion forums and measur