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 ¹.

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 ²; 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 ³ 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 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 of user and creator and no strong urge to cater to the needs and whims of the non-member. The project can stay focused on its current creators/users. New community members are usually 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.

Notes

• Note 2023-01-10: An example with some historical relevant are the 2001 Wikipedia Logo suggestions. There are some glaring problems from the perspective of graphic design, but also some very period-typical design choices. What is interesting to me is that metaphors or other associations to Wikipedia are often combined: globe+quote; books as letter W, etc. This also shows in the 2003 Wikipedia Logo suggestions: brackets+flower; book+bird, ant+book. However, there are also single-metaphor logos around ideas of a network or a book. Interestingly, the 2nd and 3rd place in the final voting were reused later as logos of Mediawiki (the Software) and the Wikimedia Foundation!
• Note: 2023-01-27, 28: Some logo competitions I found: postgraphile (with discussion), coin-OR, xmonad (with discussion), sherlock (with discussion), csploit, sailfish chum, wikifunctions (and the wikifunctions winning logo), wikidata logo voting (mostly via searching on google logo design (competition OR voting OR contest) (open source) -99designs.com or github project logo, restrict to issues). Also: Haskell 2008 (with voting, ending up with a rather professional looking one). It seems that a lot of open source projects use letters-as-identifiers and that these letters become part of logos, usually combined with some other elements. This is obvious for letter-named programming languages (R, C) but also the case for vue.js (v) and Wikipedia (W).
  • 2023-02-15: …this does not mean that letter-logos are not used for commercial projects: Word and Excel had and have letter-icons; Netscape had its N and the Internet Explorer its e. Some software actually had non-letter logos but got them later – Photoshop had an eye (version 1-7) and a feather (8-9). From version 10/CS3 in 2012 on, it had the letters Ps in a blue square.
• Note 2023-04-17: The use of clear metaphors (book=Knowledge) and known symbols that are combined (e.g.Books+W) might also ease discussion about the logos. It is easy to discuss whether the metaphor and combination is interesting or “works”; it is much harder to discuss whether the logo adheres to more esoteric qualities of design that experts would discuss (e.g. the consistency and contrast of line widths or how well the logo works in different sizes and media). Taking decisions in a group discussion is a common mode of deciding in open source projects and the discussion needs to be accessible to non-experts for this to work (here: non-experts in logo design). See Andreasen 2006 ⁷ for decisions about user interfaces and Coleman 2012 ⁸ for the role of free speech and discussion in hacker communities.
• Note 2023-06-18: Fixed some spelling/grammar in the last paragraph of the main text.
• Note 2024-01-02: The use of logos and name to create team cohesion is also suggested in Thomas/Hunt’s “The Pragmatic Programmer” (1999): “There is a simple marketing trick that helps teams communicate as one: generate a brand.…come up with a name for it, ideally something off-the-wall… Spend 30 minutes coming up with a zany logo, and use it on your memos and reports.”