What defines an open source project?

3 key elements that define every open source project

Posted 25 Feb 2015 by 

up
47 readers like this
Image by : 

opensource.com

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.

Apache
Quill

This article is part of the Apache Quill column coordinated by Jason Hibbets. Share your success stories and open source updates within projects at Apache Software Foundation by contacting us at open@opensource.com.

3 Comments

Eudris Cabrera

The community is as important as the code. All successful open source projects have a great community working behind them.
About 4 years ago, a friend of mine started working in an open source project, he invited me to join at his project and i did begin to collaborate with him.
We did the first release and was great, but couldn't get the attention of others developers and users. Sometimes, someone send us a message to thank us for the great project, but the adoption wasn't like expected.

We continue working in the project and we need your advices to get more attention from developers and users and maybe we can create a community to support our project in near future.

Vote up!
0
Vote down!
0
Shane Curcuru

Thanks for your comment! You're exactly right - trying to improve your project's brand, or the way it presents itself to the rest of the world is key to trying to draw in new contributors.

There are two parts to this: reach and interest. Working on reach - actually getting your message out to the world - can be hard, but you can do it with persistence and writing interesting content in different places.

Interest is harder. Open source is a great place to showcase new ideas. But there are so many new open source projects out there, you need to also have something interesting to draw people in. Explaining in simple ways how your product will solve user's problems for them is key - but there's often a limit to how many users actually have that specific problem. In particular, showing some companies ways that your software can solve their customer's problems is another way to gain contributors. A significant percent of all open source work - even in smaller projects - is done by company-paid engineers submitting code that they want to use for their business. If you can figure out a way to get some companies interested in your project for their own purposes, that can be good too. Just be sure you have clear licensing in place.

Thanks!
- Shane

Vote up!
1
Vote down!
0
Manrique Lopez

Yes, a project goes beyond code and the community it's one of key points. In Bitergia (http://bitergia.com) we have been analyzing FOSS communities for years, and we've seen how important are areas that usually people don't think that are connected on project success

Vote up!
0
Vote down!
0
Shane Curcuru - Ask Me about Apache! Image Credit: Julian Cash

In the open source world, Shane serves as the V.P. of Brand Management for the Apache Software Foundation, setting policy and assisting with implementation for trademarks and branding across all 200+ Apache projects and podlings, and has served as a past Director and Conferences Committee member. Much of his work happens behind the scenes volunteering with ASF operations and negotiating with trademark lawyers.

In the mundane world, Shane works at IBM as an Application Architect,