What does open source software mean? When you need to explain it to others, how can you convey the value and essence of open source efficiently? Since the term “open source” was first coined in 1997, the industry has gained many hard-earned lessons in open source that we should not forget.
For this reason, I’ve collected 12 cultural genes that, in my opinion, help share history, set the stage, and provide context for the definition of open source and its significance to the entire software industry.
The first few cultural genes relate to software construction. I believe they define what we consider successful open source projects because they address the fundamental aspects of software itself. Projects that understand these cultural genes will succeed. Software with permissive licenses and a community focus is likely our most effective and efficient mechanism for software reuse to build and maintain excellent software.
First Cultural Gene: We’ve been sharing software since we started writing it.
In the late 1950s, IBM started a computer conference that continues to this day called SHARE. DEC established support for the DECUS community in the 1960s, where you could buy tapes filled with software written and contributed by others at their meetings. USENIX originated in the 1970s, coinciding with the release of early UNIX versions on tape. But this practice of sharing can be traced back to development work on the first programmable computers at the Institute for Advanced Study in Princeton in the 1940s.
Second Cultural Gene: Writing good software is hard work.
I believe sharing boils down to this simple reality: writing good software is difficult. There are two key ratios in software development: the average number of lines of code a developer can write in a day, and the number of errors per thousand lines of code in a reasonable development process. All progress in software, from language evolution to architectural reuse, revolves around this central idea: writing more and better software with fewer lines of code. Advances in software construction reliability, configuration management, review tools and processes, and testing all aim to reduce the number of errors in a reasonable software delivery process.
Third Cultural Gene: There is no scale without discipline.
Writing good software requires discipline. If you look at software that is a successful product or open source project, it is typically built with peer review, version control and configuration management, and build automation and testing frameworks that evolve with the software. Without review, configuration management, and build and test automation, software cannot scale within a user community or as a product among thousands of users. The core team that maintains the software must be able to answer “what does the software do.”
Linus’s Law can be broadly stated as “given enough eyeballs, all bugs are shallow.” I believe this actually underscores the importance of the commit review process. Studies show that more bugs are found during review than during testing. A healthy community will have a strict review process for code check-ins.
Fourth Cultural Gene: Software is inherently dynamic.
Programs improve with use. Bugs are found and fixed. New uses are discovered, driving new features. Programs are constantly refined and strengthened. They are ported from one environment to another. Unfortunately, copyright became a mechanism to “protect” software distribution channels in 1980. People may not understand how quickly software evolves, how quickly derivatives are developed, or how this dynamism only accelerates with the advent of the Internet of Things and the World Wide Web. Our shared network bandwidth has evolved from tape-sized pockets, conference schedules, and magazine publication delays to round-the-clock real-time global building, releasing, and maintenance.
Let’s look at some cultural genes related to the community aspects of open source software.
Fifth Cultural Gene: You always get more than you give.
This is the economic efficiency of community collaborative development. Continuous contribution is the lifeblood of a project’s software evolution. Contributors risk little by contributing code or providing fixes, but gain the benefit of being able to use the entire software as they see fit. For drive-by contributions, this may be the only significant contribution a developer makes, regardless of their experience and expertise.
The return being greater than the contribution applies to both individuals and companies. Dedicated resources and investments from large companies like Red Hat, Intel, and IBM have allowed them to pursue different business strategies through the entire Linux operating system. Companies can turn excellent software projects into products that solve customer problems.
Sixth Cultural Gene: Freeloaders are key to success.
The conventional wisdom is that for every 1,000 users of an open source project, 100 may report bugs, 10 may contribute potential fixes, and only 1 carefully reads the contribution guidelines. In reality, there are three paths to community success (measured by code contributions). First, the software needs to be exceptionally easy to install and use, so the project gains many users. Second, there will be developers in the user base. The software needs to be exceptionally easy to build and test, so developers who want to make changes (for their own benefit) can do so easily. Third, it needs to be exceptionally easy to contribute changes back to the project, so contributions keep coming. Having many freeloaders means you’re doing something right. With many users, there’s great potential for developers, and contributions will follow. But it’s the project’s responsibility to ensure ease.
Companies trying to build open source projects often struggle to understand the community. They think someone has to provide something for them. They’re used to dictating to communities (like developer websites) rather than collaborating. Three cultural genes apply to companies and open source.
Seventh Cultural Gene: Don’t confuse products and projects.
A project is essentially a set of working software that can be installed and run to solve a problem. It’s a collaboration and communication that speaks through code. You need to understand that a project is not a product. A product is something that makes money by solving customer problems. While many excellent software products come from well-run open source projects that reduce some engineering work, there’s still hard work to turn it into a problem-solving product for customers. For example, the Linux kernel is a project, Fedora is a distribution project, but RHEL is a product. Products make money by meeting customer expectations for value. Products come with default installation, operation, guarantees and indemnities, services (support, upgrades, training, and consulting), and product-specific documentation. They may be part of a larger product portfolio including hardware and services.
A corollary to this cultural gene might be: “No one will build your product for you.”
Eighth Cultural Gene: Don’t confuse customers and community.
If the seventh cultural gene is about engineering and business models, the eighth is about messaging and sales. Communities and customers have different values. Customers pay to accelerate problem-solving and eliminate risk, while communities (and individuals within them) collaborate to build their own solutions. Some companies using open source software think the project community is part of their product pipeline; they further this belief when they find customers in community forums. They may even think community projects are a try-before-you-buy arrangement. But all of this is wrong.
Companies communicate with their communities differently than they do with paying customers. Each interaction has specific tools, rules of engagement, and metrics that need to be recorded and considered. Community members are highly valuable, but they are not customers.
Ninth Cultural Gene: Companies shared permissively licensed software long before the open source definition.
Project Athena (X11, Kerberos) started in 1983. The Open Software Foundation (OSF/Motif, OSF/1) started in 1988. DEC and Sun developed Ultrix and SunOS respectively from early BSD versions. This is not a new behavior.
Finally, a few cultural genes relate to licensing and legal discussions around open source software.
Tenth Cultural Gene: Software freedom and open source licenses are different discussions.
Arguing about software freedom versus open source software is like arguing whether democracy is better than capitalism, or whether freedom of speech is more important than free markets. These are important discussions in themselves, and people often have natural inclinations towards one topic or another, but they are different discussions. Software freedom language is defined by user rights, while open source software language is defined by license attributes. These are different discussions.
Eleventh Cultural Gene: Every open source project needs a license.
The license defines how others can use the software. Software is protected by copyright law, and you need to choose an OSI-approved license. The license you choose declares the kind of social contract you want in the community. While many people have defaulted to the Apache Software License as “business-friendly” in recent years, it may not always be the case. Copyleft versus permissive licenses is not about free software versus open source software. Copyleft licenses may be the best for ecosystem friendliness.
Twelfth Cultural Gene: Foundations have their place.
Nonprofit organizations can provide a level playing field and neutrality in IP (intellectual property) ownership, allowing companies to focus on a well-run open source project.
Conclusion
In the mid to late 1990s, my colleagues and I started a software company using permissively licensed software before the term “open source software” was coined. It wasn’t really mysterious. We collected and ported about 250 packages under 25 different licenses (including Berkeley, MIT, and GPLv2), combined with our own software, and some important software owned by Microsoft whose licenses allowed us to use it. We developed it into a product that our company fully supported, using our own product license. We participated in those different collaborative communities in different ways. As a group of engineers and business people, we were able to grow in the UNIX system community thanks to a long history of collaboration and sharing.
Looking back at these cultural genes, I believe they are identical to what I would have written 20 years ago.
What cultural genes would you add? What lessons have you learned? Welcome to leave a comment and share.
Reprinted with permission: Developer Relations »
