Logo Competitions in Open Source Software Projects

I always wondered why open source projects love community-driven logo competitions (almost all logos of Wikimedia projects seem to have been created this way). What happens is this: A person or a group makes the case the the project needs a logo or needs an improved logo. If they are successful in making this case, members of the project’s community will create logos, present them to other community members and discuss them. For presenting and discussing they usually use platforms they use anyway: An issue tracker or a Wiki for example. Often, there will be a voting on the logo proposals which ends the logo creation process by declaring a winner by community vote.

From a designer’s perspective even competition-winning logos have flaws like slight mismatches of colors, strokes or positions, lack of distinctiveness in small sizes, or strong reliance on easy-to-recombine elements like letters or merged geometric shapes 1.

My first explanation was that the practice shows that design is not valued as a craft in open source project communities. This might be true as their focus is code and producing software. But “Does not value the craft” does not explain why they do not get a logo by some other convenient source. An owner of a small family business might also not “value design as a craft”. But when they need a logo, they probably take a stock logo, type their business’ name and pick their favorite font, or ask a family member who is “good at arts”. However, the certainly do not suggest their customers to hand in logos and participate in a long discussions and a voting on which to choose.

I suggest that the practice of community-driven logo competitions in open source communities makes a lot of sense if the logo is primarily a representation of the project to people who are already community members. Thus, the project logo is similar to the emblem of a football club: It needs to appeal to fans of the club itself. Whether it appeals to fans of other clubs or even non-fans in general is not relevant.

The community of an open source project is community/users/creators all in union 2; thus representation to non-members is not a large concern as long as members are doing well and identify with the project and its representations (like a logo). One way to create identification of existing community members with the logo is having these community members design the logo, discuss it and then decide in a voting process which ensures a decision is made even if no clear “best” logo can be decided upon by rational means.

This is very different for logos for non-open source projects like commercial products. In these cases, the logos are created primarily as representation to non-members of the product-creating organization. The Logo of Coca-Cola is not primarily valuable because the people working for Coca-Cola like it 3 but because it helps to sell coke to people not working there: The customers. Thus, people from the “inside” of the organization probably should not design the logo; they are not the group it needs to appeal to. Instead, the logos are created by marketing and design experts who know about non-members, their preferences and imaginations.

The strong separation of outside an outside that needs to be reached out to and inside that created products for the outside makes sense for commercial products. But for open source community projects, there is no such separation or user and creator and no strong urge to cater to the needs and whims of the non-member. The project can stay focused to its current creators/users are not recruited by changing the project or its representation to appeal to non-members. Instead, new members are recruited by convincing them that the project and its communities are already good places to become a fellow user/creator.

Logo-competitions among amateurs might lead, from the perspective of the designer, to flawed designs. But they seem to work well in the context of values and concerns in open source projects as they create identification for the community from the community.


  1. It is suprisingly difficult replicate the success of peer production in open source for non-code projects, see Duguid 2006 5 and Hill/Monroy-Hernández 2013 6 

  2. In The Cathedral and the Bazaar 4, the ideal user for an open source project is also a co-developer: “Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging” and the need for building the project comes from a need of the creator themselves: “Every good work of software starts by scratching a developer's personal itch”. See also The user in the cultures of UX design and open source (on this blog) 

  3. Though it is certainly good for the company if employees have a sense of belonging to the company and how it is represented. 

  4. Raymond, Eric. 1999. „The cathedral and the bazaar“. Knowledge, Technology & Policy 12 (3): 23–49. 

  5. Duguid, Paul. 2006. „Limits of Self-Organization: Peer Production and ‚Laws of Quality‘“. First Monday 11 (10). https://doi.org/10.5210/fm.v11i10.1405. 

  6. Hill, Benjamin Mako, und Andrés Monroy-Hernández. 2013. „The cost of collaboration for code and art: evidence from a remixing community“. In Proceedings of the 2013 conference on Computer supported cooperative work, 1035–46. ACM.