This is the second article in our open source series. After having briefly discussed the history of open source in the first article, let’s focus now on the several dimensions or layers of FOSS (Free and Open Source Software). We won’t linger much on the development side here. Obviously, coding is a large part of Free and Open Source Software (FOSS) but it’s only the tip of the iceberg. As we wrote in the first post of this Open Source Series, the evolutions of both FOSS and of the Internet are interleaved and interrelated. One of the biggest disruptions that FOSS created regarding coding is collaborative development. FOSS generated several methods and tools to coordinate and organize projects with many developers spread around the globe. Distributed Versionning Systems like Git, bug and case management systems like BugZilla, continuous integration and nightly builds, quality tools like SonarQube, etc. Today, all these tools have been adopted into our companies and are used every day as commodities by enterprise developers to design, build and implement industrial development pipelines. More recently, FOSS reinforced this trend with DevOps tools and methods, largely promoted by Open Source native companies like the Internet giants. So yes, FOSS is a major source of IT industrialization and will continue to be so.
And this fact is the consequence of the specific nature of FOSS and its underlying dimensions. Let’s dive a little bit further into these specifics. Because as the title of this post claims: FOSS is not only about code.
Free and Open Source Software do have clear, standard definitions. They are described from a legal perspective.
The Free Software Foundation (FSF) defines four essential freedoms that a free software license must ensure. The Open Source Initiative (OSI) also states a definition in ten points for an open source license. Basically, FOSS is a legal object materialized through a license defining the dos and don’ts of its use, modification and distribution.
To use FOSS in the most efficient and safe way it is though absolutely necessary to have some legal awareness. And this is required not only for legal staff but also for every stakeholder, starting with the developers themselves. For instance, it might be easy to integrate FOSS components or code in an enterprise project to accelerate the time to market. But it is imperative to understand the legal impacts of such uses. Developers and all layers of management have to be aware of FOSS specifics like license compatibility or copyleft and impact on existing code.
For example, a few years ago, a controversy grew around the GNU GPL v3 license when it was first published. This license is often described as viral because it requires that any derivative work to also be distributed under a GPL compatible license. This was illustrated in 2011 by the obligation for the French ISP “Free” which was assigned in justice to publish all its source code using free software on his website. Some IT companies try to restrict GPL’s use in favor of more permissive licenses like MIT or Apache.
When distributing software including FOSS, it is also key to understand how FOSS is related to intellectual property, trademarks and patents. We will detail all these legal aspects and related best practices in a future post of the Open Source Series. At this stage, just keep in mind that legal awareness is part of the FOSS history and culture. Such a legal awareness is therefore highly recommended to embrace FOSS in the best way: reduce the risks and get the most value.
New business models
And subjects like risk and value naturally lead us to deal with business aspects. Again, we won’t detail and motivate here the benefits of FOSS and of its adoption in the enterprise world. Few years ago they were a lot of analysis, discussions and debates on cost reduction, durability, innovation, interoperability, vendor locking… At the end of the day enterprises have largely adopted FOSS because it is good for their businesses. The question about FOSS adoption is not “why” anymore but “how” to do it.
It is largely accepted today that there is no issue about making money with FOSS. FOSS licenses never prevented this as long as free software freedoms or the open source definition are respected. Like Richard Stallman said: you should think of “free” as in “free speech,” not as in “free beer”.
Several business models emerged around FOSS. In a nutshell they participate in the value shift from software to services. The market value of FOSS is less in the code itself and more on value-added services like packaging, support, training, expertise or innovative features. Legal aspects of FOSS also stimulated new business models based on dual licensing: a copylefted component the use of which would have an impact on other components can also be acquired under a proprietary license, from an enterprise owning the intellectual property and without “contaminating” associated contents. This is the case of MySQL which can be purchased under a proprietary license for OEM and not under the copylefted GNU Public license.
Today several business models coexist around FOSS like opencore, freemium, subscriptions, version lag, certification… We will discuss them in a future post of this Open Source Series. For now just remember that making money with open source is allowed and is not evil. The recent acquisition of Red Hat by IBM is a perfect illustration of this point.
On the other side there should be no issue about spending money on FOSS either. The time where FOSS was adopted only because it was free is past or should be. Even if an enterprise adopts community software without additional services it will have to internally invest into its packaging, industrialization and support. So the Total Cost of Ownership can’t be reduced to license fees. Furthermore FOSS adoption shouldn’t be reduced to TCO (Total Cost of Ownership) but also include strategic aspects like business alignment, external communication (to market, customers and talents) or innovation booster.
One very good way to get the best value from FOSS is by contributing. This is how, for instance, enterprises can share maintenance costs even on modifications they made on software. But contribution is not only about code, it can be by promoting FOSS usage, sharing expertise, documenting, translating, helping new users… basically by being involved in FOSS collaborative processes.
And to be able to collaborate properly it is important to know, understand and embrace these processes. FOSS communities each have their own culture and etiquette and they differ to one another. So stay humble, observe and learn. For instance a major contribution from an enterprise is more likely to be integrated in the mainstream version of a project if it is made after contributing patches and contacting the core developers to discuss the contribution to be made. The enterprise’s initial requirement might be transformed in a more generic feature set and the development efforts can even be shared with the community.
IBM is one example of major open source company contributor. Through the Eclipse.org foundation and beyond, IBM has been donating some projects, and technologies to the open source community. For example, IBM donated in early 2000 some libraries such as xerces or xalan which enabled to manipulate XML documents. Recently, IBM has open sourced its Java Virtual Machine OpenJ9.
Some communities are very organized with clear roles, responsibilities and road maps. Some not so much or getting there. But even if the collaboration processes are not explicitly formalized they still exist and must be taken into account.
By understanding how to collaborate and contribute to a FOSS project and being part of its community, enterprises also gather key information regarding the legal and business dimensions discussed earlier. For instance, who will own the intellectual property of the contribution and is it mandatory to sign a Contributor License Agreement (CLA). Her are some examples of such CLA from Microsoft, Google or Ubuntu.
Whatever the specific collaborative processes in place, they are two main principles that are commonly shared in FOSS projects: transparency and meritocracy. Transparency is key and at the very core of FOSS. When you share, you show. So no need to be secretive or shy. FOSS communities respect transparency and can become suspicious or even hostile when it is lacking. Power and responsibilities are often set in FOSS communities on effort, talent and achievements. FOSS communities can be more or less meritocratic based on their own culture and business model, but individuals or companies will have to prove themselves in a way or another. We see how transparency and meritocracy are two sides of the same coin.
FOSS communities being a reflect of our society, many of them recently decided to formalize codes of conduct to be more respectful of human beings and their diversity. Several major communities adopted the Contributor Covenant, some created their own. For instance the Linux kernel project, under the pressure of its community complaining about how badly new comers were sometimes welcomed, released its Contributor Covenant Code of Conduct.
At its core FOSS is about people
Having visited the technical, legal, business and collaborative dimensions of FOSS we must highlight one final major aspect: FOSS is at the end about people. FOSS projects and communities are made of individuals with their own beliefs and values. A FOSS developer, even paid by a commercial open source vendor, is passionate. Successes like Linux were and still are built with passion.
Aaron Swartz was one of them. Before being an Internet Hacktivist, he was involved in the development of the RSS standard, the Creative Commons licenses and also the Markdown language which is hugely used today to publish content on Internet. Despite his young age, he became a recognized member of several working groups with more seniors experts and members (IT engineers for most of them) and participated in the realization of all these initiatives.
Enterprises should understand and consider this aspect because, even if it is not easily quantifiable, it is a key factor of success of FOSS adoption. Therefore FOSS contribution should be promoted and rewarded, if it is in line with the enterprise strategy and guidelines of course. Contributing employees can then become real innovators and strong links with FOSS communities.
It is also a very efficient way to recruit talents, spreading to young passionate developers to senior lead FOSS actors. Internet giants like Google, Facebook or Microsoft are very aware of that fact and employ many FOSS experts. Interpersonal relationships built on shared passion are very strong and often survive business contracts or collaborations. Developers might change of employer but they still keep contributing to FOSS projects. Based on meritocracy, they can obtain responsibilities and be hired by specialized FOSS companies or even create their own. There should be no problem with that. Talented developers are always very popular profiles. With FOSS transparency they even are known and visible to the entire world. So one good way to retain them is to let them live their passion while bringing a lot of value to their enterprise and also becoming their best advocates outside.
The ultimate way of contributing to FOSS is to contribute developers: with dedicated time to FOSS contribution or even by letting them leave the company to get completely involved in projects and communities. Because FOSS is about people, their enterprises of origin will always benefit from their expertise, in a different but still powerful manner. Jessie Frazelle is such a developer: she started contributing on Docker, got hired by Docker Inc., then by Google and now by Microsoft. But she is still strongly involved in Docker and Kubernetes communities.
This was a short overview of specific aspects that have to be taken into account when dealing with FOSS. Not reducing it to only code is the best way to better understand and benefit from it.
Future posts of the Open Source Series will detail further some of these dimensions like legal and business aspects.