Patrick Masson

It's great to see where open source software and the communities that support it are today. Many of those who have worked over the years to develop feature-rich applications and enterprise ready systems, that not only compare to, but exceed proprietary options, must feel like pinching themselves.

Long gone are the arguments around viability (is the open source option “enterprise ready?”) and feasibility (does the community have the expertise and resources to support the software?). Indeed everyday there seems to be another news story (e.g. “open source goes mainstream,” http://tek.io/11q1yI0), blog post (e.g. “open source offers a better way,” http://bit.ly/1HPeloQ) and company (e.g. Microsoft, http://bit.ly/1v3QXjp) or government (e.g. NSA, http://1.usa.gov/1tseO5D) press release about how open source software is enabling innovation (“There are thousands upon thousands of open source projects that bring about innovation,” http://tek.io/RXL9Ws), reducing costs (“reaped 50 per cent in savings for a key website just weeks after embracing open-source,” http://bit.ly/1B2Z6qo) and furthering business (“IT Pros Prefer Open Source for Continuity, Control”, http://bit.ly/1FoaJGl).

Yes, it would appear “open source continues to eat the software world” (http://bit.ly/1z49bPX), perhaps even the whole world (http://bit.ly/1p9tOVP). Unfortunately, as organizations who actively and authentically participate in the development of software distributed with an OSI Approved License reap the business, economic, operational and technical benefits, as well as garner public accolades and increased profile from that success, “open-washing” becomes more prevalent.

IFAIK, Michelle Thorn, Mozilla’s Director of the Webmaker Program, was the first to define “Openwashing” in 2009: “Openwashing: to spin a product or company as open, although it is not. Derived from “greenwashing” (http://michellethorne.cc/2009/03/openwashing/) – which should not be confused with “The Open Source Washing Machine” (http://www.oswash.org/). Also in 2009, Phil Marsosudiro (http://www.realgoodwork.com/about-us/about-phil-short/), coined a similar concept, “Fauxpen,” which is defined as “A description of software that claims to be open source, but lacks the full freedoms required by the Open Source Definition” (http://www.fauxpensource.org/).

Sadly this is the negative impact of open source software's success. I'm seeing more and more companies, undertaking more and more egregious marketing and promotion schemes that exaggerate their participation in / contributions to / licensing of open source software. The goal of these unscrupulous organizations is to capitalize on open source's success and the growing interest (and investment) it is enjoying, by duping a naive audience which is just beginning to engage with open source software and the communities that support it.

Unfortunately growth and interest in open source software has occurred faster than many organizations' knowledge and understanding of the principles and practices that promote development, foster community and ensure collaboration. Many organizations have standard operating procedures dealing with the acquisition of new software—procurement or purchasing departments, requests for proposals, bid processes, contracting, etc.--all of which are designed to ensure due diligence is carried out and that what a company claims can be delivered, is delivered. Also common within many organizations as well, are policies and processes for managing and transferring intellectual property portfolios, again most often tailored for working in a world of proprietary software. Within these practices are terms and concepts most purchasing agents, directors of procurement, contract managers, lawyers, etc. understand, in fact, expect. Open source software often pushes the limits of these folks, their departments and the organization with not only new "best-practices" to incorporate but a new vernacular as well.

What do developers, evangelists, marketing folks and others mean when they use the terms “open,” “open source” or “open source software”? Are these terms' definitions consistent across the sector? Will some—either purposefully to take advantage of, or naively out of ignorance—use these terms to imply something different than what the audience may assume? While the Open Source Initiative maintains the industry recognized “Open Source Definition” (http://opensource.org/osd) and certified licenses as “OSI Approved Open Source Licenses,” many new to the sector may not be familiar with these standards or how they are applicable to community and development practices. Even those who have invested in understanding the open source ecosystem may struggle with applying traditional practices, tuned for proprietary software, to open source models. For example, who do you send your RFP to for Drupal, Android or Hadoop? Yes, there are several companies who offer professional support and services for these projects, but they only become relevant after the decision to use a particular system has been made. If an organization, like many do, is using the RFP process to understand what software can meet their requirements, say reviewing web CMS's, they'll want to include Drupal, Joomla, Typo3, Wordpress, and others before they contract for support for one of those platforms from a professional services provider. Sadly, with more and more organizations interested in open source software come more and more charlatans to take advantage of this new market and the gap in knowledge for those entering that market.

If these issues are tough for large, resourced organizations, imagine how tough things are for small companies, other open source projects, and even individuals who may not have the expertise, time or money to assess the actual status of software touted as open source? Add to this the complexities in software architecture, distribution and integration where, “based on open source,” “built on open source” and “supports open source” are common, and the challenges only grow for the uninitiated. The cruel reality is, the ultimate responsibility is on the end-users to review the software and accompanying license to ensure it meets your expectations: “adopter beware.”

Fortunately there are a few good pieces of advice already out there: How to Spot Openwashing (http://bit.ly/1Ctf4vM), and; Beware of Open Washing – Three Key Questions To Ask Your Software Vendor (http://bit.ly/1uXK0u8). These two articles provide a starting point for organizations looking at open source options to assess, not only the open source software's availability through an open source license, but also the communities that support it.

In addition, there are two projects I am aware of that are trying to help address this issue, i.e. accuracy and authenticity in open source software. Importantly both these efforts are not limited to the software licensing aspects, but also the organizational model (development practices, decision-making, roles, governance, etc.) supporting the open source project. These are The Open Source Score Card (http://opensource.org/node/476) and, The Openness Index (https://wiki.jasig.org/display/2398/Openness+Index).

Until the open source software movement matures even further, becoming sophisticated enough to recognize open from fauxpen, many may fall victim to the openwashing of unscrupulous businesses and organizations. When considering the adoption of, or a contribution to, any organization touting their open source support, please be sure to investigate the community thoroughly. You'll find those organizations that are authentically engaged in the development of open source software are welcoming to you as a “newbie,” and appreciate your diligence and interests because they too want to protect their work, reputation and the open source label.

Best of luck.
Patrick

Luis,

Thanks for sharing this. Indeed I can't help but compare these tangible, examples to some of the often over-hyped trends promoted in higher education.
<ul>
<li><b>Peer-to-peer learning (connectivist, constructionist) pedagogy:</b> Not only do these courses foster peer interactions within the course, but also out into the broader community of practice supporting the open source project as well. Students learn both the mechanicals of creating/contributing code, ad also participation and collaboration skills for working within a community of practice. As open source tools and development continue to grow across the technology industry (as well as other sectors), these skills will be (are) tremendously valuable.</li>
<li><b>Online learning:</b> While many most often think of a "learning management system" as the platform for online education, the use of real-world tools like GitHub, bug reporting/issue tracking systems, discussion forums, and even email lists, provide an infrastructure very much like what students will find in their careers (arguably even if they end up outside IT).</li>
<li><b>Hybrid courses:</b> Many courses are adopting a hybrid approach where teaching and learning occurs outside the course. I can't think of a better example of this than the interactions students must be having with those outside the course within the Linux Kernel community who offer feedback, suggestions, etc. on their work and working habits.</li>
<li><b>The flipped classroom:</b> This model, where students "watch the lecture" outside the class and work on "homework" during the class, allows the faculty and other students to work together--referencing foundational knowledge acquired during the lectures--to understand the application of that knowledge through personalized and "just-in-time" teaching. Again, these courses sound like they provide just that experience.</li>
<li><b>Problem based learning:</b> Well I hardly thing an explanation is required for this one. It sounds like the course is providing actual problems and asking the students to investigate and solve these.
</ul>
Too often the above practices are promoted as "disruptions" with little authenticity in approach or discipline in practice. What you've described highlights the possibilities when institutions and faculty choose to invest in such models. The reality is, we need more creativity, motivation and authority for faculty to develop programs like these, not simply presentations at edTech conferences by rock stars.

Thanks again for sharing this,
Patrick