What does open source software mean? When you are explaining it to someone else, how do you convey the value and essense of open source without reinventing it? There have been many hard won lessons in open source since the phrase was first coined in 1997, and we should not forget those lessons.
To help with that, I've collected 12 memes that are meaningful to me to help share the history, set the stage, and provide context for what open source software is and what it means to the software industry at large.
These first memes relate to software as it's constructed. I believe they define what we see as successful open source projects because they are fundamentals about software itself. Projects that understand these memes succeed. Software that is liberally-licensed and worked on in communities may be the best and most efficient software re-use mechanism we have for creating and maintaining good software.
Meme #1: We have shared software since we have written software.
IBM began a computer conference in the late 1950s that continues to this day called SHARE. DEC started in the 1960s and supported the DECUS community, where you could purchase at their conferences (for the cost of the media) mag-tapes full of software that was written and contributed by other people. USENIX began in the 1970s concurrent with the tape distributions of early UNIX releases. But this sharing goes all the way back to work on the first programmable computer in the 1940s at the Princeton Institute of Advanced Studies.
Meme #2: Writing good software is hard work.
I believe that sharing comes down to the simple reality that writing good software is difficult. Two ratios dominate software creation: The number of lines of code an average developer can write in a day, and the number of errors per thousand lines of code from a reasonable process. All software advances from language evolution to architecture re-use have been about trying to write more and better software with fewer lines of code. Advances in software construction reliability, configuration management, review tools and processes, and testing are targeted at reducing the bug count from a reasonable software delivery process.
Meme #3: There is no scale without discipline.
There is discipline that goes along with writing good software. When you look at software that succeeds as a product or an open source project, it is generally peer-reviewed in its creation, version control and configuration management is present, and build automation and testing frameworks evolve with the software. Without reviews, configuration management, and automation of build and test, the software can’t scale in a community of people using it, and it can’t scale as a product with thousands or millions of users. The core group that needs to maintain the software has to be able to answer "what software is executing." Otherwise it's chaos and there can be no growth.
Linus's Law is loosely stated as "given enough eyeballs, all bugs are shallow." I think it’s actually a statement about the commit review process. Studies demonstrate more bugs are caught in review than testing. A healthy community invariably has a disciplined review process on check-in.
Meme #4: Software is inherently dynamic.
Programs evolve through use. Bugs are found and fixed. New uses are discovered that drive new functions. The programs are honed and hardened. The program is ported from one environment to another. And, it is unfortunate that copyright became the way to "protect" the software distribution pipeline in 1980. People may not have understood just how fast software evolves and derivatives are created, or that dynamism has only accelerated with the evolution of the Internet and the World Wide Web. Our sharing network bandwidth has gone from mag-tape-sized packets and conference schedule and journal publication latency to real-time global creation, distribution, and maintenance around the clock.
Let’s look at a couple of memes relating to the community aspects of open source software.
Meme #5: You always get more than you give.
This is the economic efficiency of collaborative development in community. Contribution flow is the life blood of the evolution of the project software. A contributor risks little giving a contribution or a bug fix, but gains an entire working body of software to be used as the contributor sees fit. And for drive-by contributions, that may be the only substantial contribution the developer had to give regardless of their experience and expertise.
Getting more in return than was contributed applies to companies as much as individuals. The dedicated resources and investments from Red Hat, Intel, and IBM to name a few, allows each of them to pursue different business strategies with an entire Linux operating system. Companies can shape good software projects into products that solve customer problems.
Meme #6: Freeloaders are essential to success.
It has been anecdotally observed on occasion that for every thousand users of an open source project, a hundred people may report a bug, out of which ten people contribute a potential fix, and only one of those read the contribution guidelines. The reality is there are three on-ramps for community success as measured in contribution flow and growth. The software needs to be blindingly easy to install and use, so the project gets lots of users. Out of the user base, there will be developers. The software needs to be blindingly easy to build and test to a known state, so developers that want to change something (for their own selfish interest) can easily do so. The ability to contribute a change back to the project needs to be blindingly easy, so that contributions flow. Lots of freeloaders means you're doing it right. With lots of users, comes the potential for developers, and the possibility of contributions. But the onus is on the project to make it easy.
Companies that try to create open source projects often have a tough time understanding communities.They think some how someone should be giving them something. They are used to broadcast communities (i.e. developer networks) and not collaboration. There are three memes that apply to companies and open source.
Meme #7: Don't confuse products with projects.
A project is a collection of working software that installs and runs and solves an interesting problem. It's a collaboration and conversation in code. Projects are NOT products. A product is something that solves a customer's problem for money. While a lot of excellent software can come out of a well-run open source project that relieves some of the work for engineering, there is enormous work still to be done to turn it into a problem-solving product for customers. The Linux kernel is a project. Fedora is a distro project. RHEL is a product. Products meet customer expectations of value for money. They install out-of-the-box, run, and come with warranties and indemnifications, services (support, upgrades, training, consulting), and product specific documentation. They may be a part of a larger portfolio including hardware and services.
A corollary for this meme might be: "No one is coming to build you product for you."
Meme #8: Don't confuse customers with community.
If Meme #7 is about engineering and business model, Meme #8 is about messaging and sales. Communities and customers live in different value spaces. Customers spend money to expedite a solution and remove risk, while communities (individuals in communities) collaborate to build their own solutions. Some companies using open source software think that the project community is a part of the product pipeline, and they further believe this when they find customers in community forums. They may even think the community project is a try-before-you-buy type thing. All of this is wrong.
The conversations that a company has with its relevant communities versus paying customers are different. Each conversation has specific tools and rules of engagement, and metrics to capture and consider. Community members are incredibly valuable, but they're not customers.
Meme #9: Companies shared liberally-licensed software long before the open source definition.
Project Athena (X11, Kerberos) began in 1983. The Open Systems Foundation (OSF/Motif, OSF/1) started in 1988. DEC developed Ultrix and Sun Microsystems developed SunOS out of the early BSD releases. This is not new behavior.
Finally, a few memes about licensing and the legal discussions around open source software.
Meme #10: Software freedom and open source licensing are different discussions.
Arguing about software freedom versus open source software is like debating whether democracy is better than capitalism, or free speech is more important than free markets. They are each important discussions in their own rights, and people often have a natural affinity for one subject or the other, but they are not the same discussion. They are not end points on a continuum. The language of software freedom is defined by the rights of users. The language of open source software is defined by attributes of a license. These are different discussions.
Meme #11: Every open source project needs a license.
Software is covered by copyright law. The license defines how other people can use it. Choose an OSI approved license. The license you choose is a statement about the social contract you want in community. While lots of folks in recent history have defaulted to the Apache Software License as the "business-friendly" license, it may not necessarily be so. Reciprocal licenses versus permissive licenses is not a discussion about free software versus open source software. Reciprocal licenses may be the best ecosystem friendly licenses.
Meme #12: Foundations have their place.
Non-profits can provide the level playing field and neutrality of IP (intellectual property) ownership that enables dedicated company investment in a well-run open source project.
Final thoughts
In the mid-to-late 1990s, colleagues and I built a software business out of liberally-licensed software before the term open source software had been coined. There wasn't a lot of mystery in it. We collected and ported on the order of 250 packages covered by about 25 different licenses including the Berkeley license, MIT license, and the GPLv2, along with our own software, along with some substantial software owned by Microsoft and covered by their license to us. We developed it into a product that we stood behind as a company, and the product was covered by our product's license. We participated in those different collaborative communities in different ways, as appropriate. As a group of engineers and business people, we grew up in the UNIX systems community, so we had the benefit of a rich history of collaboration and sharing on which to draw.
As I look back across these memes, I think they're the same memes I would have written down 20 years ago, but perhaps without the crispness that comes from history and experience.
What memes would you add to the list? What experiences did you have?
8 Comments