The “Ultimate” Benefits of Open Source List

Frequently I catch presentations on the benefits of open source software, or even other open initiatives like open educational resources, open courseware, open access, open etc. Usually, the greatest benefit in the adoption of open source software cited by the presenter (especially when talking about applications within higher education) is related to cost savings realized by the lack of licensing fees. Little, however, is ever mentioned about the actual development methodology openness enables (as opposed to distribution) and the benefits such an approach has on the final software project.

In a recent post to the Educause CIO list I noted:

I would offer as an example, eight of the ten presentations specific to the migration to Moodle in EDUCAUSE’s Moodle Resources (http://www.educause.edu/Resources/Browse/Moodle/27756) focus on cost savings and features for their evaluation (two of those mentioned features alone). One of the ten, in addition to costs and features, included the ability to customize the software as a driver, but only two of the ten included other open source values (customization, pace of development, community, quality, etc.) as well. Does this mean only 30% of those evaluating Moodle valued other qualities of [open source] important? Obviously this is not a comprehensive survey, but it highlights my point (good enough for a listserv post anyway!). I believe most campuses working with open source service providers are not really interested in the complete value proposition of open source itself, but rather, adopted Moodle to reduce costs (both LMS licensing and local hosting costs) without losing functionally. I don’t know NetSpot’s pricing model, but when I was CIO at SUNY Delhi we moved to Moodlerooms hosting when it was $1 per user – is that price still available?

In addition, every once in a while I too am asked to provide some insights on the value of open source–although to be honest, I am not usually invited, I just butt in, and offer my thoughts (see quote above). In these cases I often hit the web (again, see quote above) to find the latest news, posts, web pages on the “Benefits of Open Source.” Alas, I have yet to find the “ultimate” list, so I have attempted one for myself (many thanks to Michael Feldstein for his contributions). These are not in any order, these may not be complete, these may not be articulated in the best way. I will be happy to modify based on any feedback.

• Customizable – Ability to modify base level functionality to meet unique local needs
• Participate in project governance: anyone can contribute to defining the direction of the project: technical aspects, functionality/features priorities, decision-making, community practice, etc.
• Organizational audibility: ability to assess how well the open source community, project and governance is aligned with local (adopting organization’s) needs/goals/expectations.
• Community audibility: ability to assess what the level of shared knowledge and experience is within the community; number of participants, contributors and commiters there are in the project; what the level of adoption/deployments is.
• Business process audibility: ability to evaluate how needs are identified and assessed, how work is prioritized, what the workflows and practices are, etc.
• Technical audibility: ability to assess quality of code, architecture, development practices, etc.
• Reduced development time: more contributors and contributions to solve problems, write code, test enhancements, document versions, etc.
• Avoid vendor lock-in: not tied to, and controlled by any third party and their direction, interests, plans, migrations, enhancements, upgrades, sunsetting, integrations, dependencies, etc.
• Broader support options: options range from local internal resources, to communities of practice, and multiple commercial vendors rather than a single commercial provider (the developer)
• Greater security: vulnerabilities can be discovered more quickly (the more folks with access to the code, the more likely issues are to be discovered) with the best solutions applied to address issues (more folks involved can offer a greater variety of approaches, ideas solutions)
• Faster implementation: no procurement process
• Higher quality: meritocracy (best approach) is implemented
• Mitigates longterm risk: no chance of discontinuing development/support due to purchase, or a new version ( and thus forced migration to stay up to date with support/service contracts)
• Higher reliability: bugs will be discovered and fixed more quickly (see, greater security)
• Business/operations continuity: local organizational operations and practices are not disrupted through forced timelines for migrations, upgrades, enhancements etc.
• Professional (personal and organizational) development opportunities: individuals can gain experience through participation and organizations can gain prestige through contribution.
• Try before you buy (Test drive): assess one, or many, options, before investing.
• Multiple instances (no per copy fees): can extend use on demand without additional costs or contract negotiations.
• Reduced acquisition costs: no licensing fees
• Emphasizes concepts, not products: end users are not tied to branded or copyrighted features, workflows, tools.
• Breaks the hardware upgrade cycle: open source software is often designed to require less resource intensive hardware.
• Community access: ability to meet and network with like minded people and organizations–peers.
• Standards based: provides greater integration and interoperability (no proprietary specifications)
• Standards setting: participants are often directly involved in the development of new standards, or learn of them first.
• Lower total cost of ownership (cumulative of other benefits): no licensing fees, no procurement process, competitive support contracts (even none with internal), no forced SP upgrades, re-purposed legacy hardware, greater scaling