Openness - how open is FLOSS?

Having spent a long time in the FLOSS world both in community and industry roles, I started to see a serious disconnect between the industry and community perspectives on FLOSS about 5 years ago. I mean a disconnect that went beyond philosophical and into the practical, and this is largely because is a rapidly expanding userbase and industry around FLOSS. Community participants in FLOSS have a different understanding and expectation of openness than people in industry, and this difference is unfortunately being used to undermine the core values that make FLOSS more than just another technology set. The issue is that for all the well meaning of the 4 freedoms of the FSF or the Open Source Definition of the OSI, people can simply take those licences and not subscribe to any of the other attributes of openness that are expected of a FLOSS project and still get the good name of being a FLOSS project.

Openness has been proven time and time again to be the way forward. We saw it with TCP/IP, with HTTP, and now with FLOSS projects like Apache. Openness provides a platform for innovation, collaboration, an open and competitive market, and a sustainable approach to a digital future. In the same vein, a more closed approach may in some cases also be appropriate. For instance some  popular and successful FLOSS projects have relatively closed development models controlled by an individual or a single company. An understanding of the degree of openness in software helps people understand the implications of the software model and also the implications in using the software.

In the spirit of discovering the core principles of openness, I spent some time working on a model to help explain openness in such a way that it couldn't not be undermined. I came up with 5 Foundations of Open:

• Open Source – the conditions surrounding the project source code. Usually defined within the licence terms.

• Open Standards – the data, communication and other standards used within a project, for example, APIs, protocols, & documentation norms.

• Open Knowledge – the documentation, project information, decision making, communication archives and any other content related to the project.

• Open Governance – the structure of the organisation that defines who participates in a project and the terms of participation. Includes decision making, and any practical or policy limitations on participation.

• Open Marketplace – the ability for any organisation to build a business around a project. Includes practical, legal and technological limitations to building an open marketplace around the project.

As we can see, above is a far broader understanding of openness than is generally subscribed to. A project may decide to have a more closed approach to any of these 5 vectors, and sometimes for good reasons, however by looking at all software (not just FLOSS) using these vectors people will  be able to have a good understanding of how open the software is and what that means for using it, developing on it, building a business around it and so on and so forth.

I'm currently building some metrics around this to help determine the openness of any software, and will announce here when it is done.