Open source has come a long way in the past 30 years and is entering the consciousness of most modern cultures. When thinking of open source projects, people categorize them several ways: governance structure, type of product platform, programming language, utility, technical details (language written in), industry sponsored or fully independent, and more.
But what truly defines any open source project, making it a unique entity different from all other open source projects? I would propose that there are three key elements of any open source project that frame, define, and differentiate that project from all others: the code, the community, and the brand.
The code
Code is king. Code is what makes a product do something, and that’s why open source projects exist in the first place: to build something useful. Technologists get excited about what the code does, and how it does what it does. Marketers get excited about how the product will solve their customers’ problems. Code is what most people are looking for when they’re searching for an open source project to use.
Sounds simple enough—so why don’t we define an open source project purely based on its code? As anyone who has worked in software development already knows, code is ever-changing and ephemeral. In the open source frontier, free from the traditional controls of corporate-led projects, “the code” can get very hard to follow: open source code is infinitely forkable. Once your code is checked in under an Open Source Initiative (OSI) license to a public repository, it is fully accessible to anyone and everyone to take—and modify—for their own purposes. Once another user forks the code from your project and makes a slight modification, it is no longer officially part of your original project.
The community
If code is the “what” of a project, then the community is the “who” of the project—the people who make it all happen. The core community of a project includes anyone actively involved in moving the project forward, such as the engineers writing the code and the end users who provide feedback or request specific modifications. The overall community also includes people who don’t check code, but provide support such as governance/process oversight, public relations/marketing, training, or financial or employment support. The social norms, the etiquette, and the ethos of the community help to differentiate a project from all others.
While participation in an open source project may be part of some individuals’ paid employment (e.g. a corporate-employed software engineer assigned to work on an open source project for a certain percentage of her or his time), most open source community members participate voluntarily with no direct connection to their paycheck. So members tend to come and go as their interest or their other commitments wax and wane, or as their employer changes strategy. Like the code, the community is ever-changing.
Unlike a corporate software development project that can plan on having employees with certain skills available to assign to do specific work, the participation in an open source community is unpredictable and often beyond the control of the project. Personality conflicts arise and may result in highly skilled contributors leaving the community more readily than they would leave a paid employment. But the benefits of an open community can be seen in the enthusiasm and drive of many community members, and in the longevity of successful project communities, and in syncrhonicity and great work forward on the code.
The brand
Brand is how the world outside of an open source project learns about that project. When individuals or companies are deciding which project to use or to invest in, branding helps them differentiate projects that offer similar functionality. Of course they will consider other details, but it is much easier to think, “Do I want to support Hadoop, with the yellow elephant?” rather than “Do I want to support Cloudera’s CDH or the Hortonworks Data Platform, or the newly announced ODP?”
“The brand” includes many things: the official name of the project, a logo for the project or product, and even the appearance of the project’s website and your product’s UI. Some branding components in particular are legal trademarks: these typically include the official software product name and logo, although trademarks are strongest when used consistently.
Unlike code and community, a project’s brand is not ever-changing or ephemeral. A trademark cannot be forked without legal permission, and a project brand can stay consistent even when community membership fluctuates. In many ways, the brand and trademarks are the element of a project that can be most easily controlled and maintained. However, proper trademark usage can be overlooked—or underappreciated by the community inside of the project—as an important tool for defining a project’s unique character. Given that anyone can fork the code, and that community members come and go, a project’s brand and trademarks are crucial elements for maintaining a project’s longevity and independence, and to continue to draw in new project contributors.
This post also appears in the Apache Quill column of opensource.com coordinated by Jason Hibbets.
