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"), blog post (e.g. "open source offers a better way") and company (e.g. Microsoft) or government (e.g. NSA) press release about how open source software is enabling innovation (e.g. "There are thousands upon thousands of open source projects that bring about innovation"), reducing costs (e.g. "reaped 50% in savings for a key website just weeks after embracing open source"), and furthering business (“IT Pros Prefer Open Source for Continuity, Control").
Yes, it would appear "open source continues to eat the software world", perhaps even the whole world. Unfortunately, as organizations who actively and authentically participate in the development of software distributed with an Open Source Initiative (OSI) Approved License reap the business, economic, operational, and technical benefits as well as garner public accolades and increased profile from that success, “openwashing” becomes more prevalent.
As far as I know, 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," which should not be confused with "The Open Source Washing Machine." Also in 2009, Phil Marsosudiro, 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.
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, and 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 and certifies 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 CMSs, 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 and Beware of Open Washing – Three Key Questions To Ask Your Software Vendor. 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 and The 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.
3 Comments