E. Raymonds Essay “The Cathedral and the Bazaar” is an essay on Open Source development. It is not about open source as a legal construct but about a possible development style of bottom-up activities in a community of creators. This bottom-up style Raymond calls “bazaar” and contrasts it with the top-down-planned “cathedral” style of development1. The bottom-up style is often praised as a egalitarian, democratic model of software creation 2.
Open source programs have often been seen as hard to use. UX Designers are professionals who try to make things easier to use, so it seems to be a great opportunity to get them involved into the creation of open source applications. However, core assumptions about the development of open source software are hard to combine with the culture and goals of UX design.
User and Creator: One person or a different people?
The user in an open source project is ideally a programmer as well. Indeed, in The Cathedral and the Bazaar this is assumed to be the case:
“6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.”
“8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.“
as well as
“1. Every good work of software starts by scratching a developer's personal itch.”
Developer and user of the software, in these examples, are the same person or people being very similar.
Design, on the other hand, has a tradition of being a service for others and for people who are not designers. It is a sin-like act to assume that one is (like) the user oneself and “you are not the user” is treated as a kind of mantra :
- “Myth #14: You are like your users” (with lots of interesting links and a little list of counter-examples)
- “You Are Not the User: The False-Consensus Effect” (which interestingly starts the with a “scratch your own itch”-situation, that could also start a text on how great sharing the resulting code is!)
- You are not your user
The hard division between user and designer is plausible since UX design draws from psychology, graphic design and anthropology. In psychology and anthropology, working with people who are seen as different from oneself is frequent and graphic design is usually a service in which the designer works together with several other disciplines to create a product.
While in open source, user and creator are one person, in UX design user and creator are separate. The creator is working for the user and the user is assumed to have a different perspective than the creator.
Something that might be normal in “Bazaar” development, like “trying to add a feature and see how that goes” would be strange for the UX designer. Vice-versa, the designer asking of “what users actually need” might be strange to the bazaar-style-developer.
The whole and its parts: coherence and competition
How parts can work together in open source is what the metaphors of Cathedral and Bazaar are about: the cathedral stands for centrally organized, coherent planning, the bazaar is self-organizing, a marketplace with many players. "The Cathedral and The Bazaar" praises the Bazaar model of development and suggests principles for it to work well. The basic principles are self-organization and competition. The single actors might be different, but they are held together by some basic rules of the metaphorical marketplace. These basic rules need to be set, too: Raymond: “It's fairly clear that one cannot code from the ground up in bazaar style”, and successful bazaar projects like “Linux and fetchmail both went public with strong, attractive basic designs.”.
In design, in contrast, coherence of the outcome is an important value, leading to aesthetics as well ease-of-use, since what one learned once is applicable to all parts of the product.
If the user and creator are the same person, the modularity, exchange and freedom at the bazaar are great and the skill of the person will allow dealing with minor obstacles in use. If the users and creators are separate, the cathedral model if often favorable, since it ensures a coherent outcome and the gains of the bazaar model do not exist for the non-programming user.
The effect on how software appears to its users
The bazaar model favors user-creators and modularity, while the cathedral model makes coherence for users more likely to archive.
The choice of interface for a bazaar model is thus likely to be a command line: It allows heterogeneous software to be combined to work together 3 and its relatively simple linear, text-based structure allows only limited user interactions which avoids overly complex interfaces and inconsistencies.
In contrast, a graphical user interface which is “good” according to designers is likely to be hard to build in a bazaar model of development: For an graphical interface to be consistent, you need some sort of central rules, defining how to do what in the graphical interface. Such rules are unlikely to emerge from the bazaar: The important thing is to have them, which ensures consistency rather than finding the best possible via a competition of rules. It is theoretically possible for such rules to be defined by a project’s leader, overseeing the bazaar. The project leader, however, is most likely a programmer-user and thus unlikely to have their core competencies in defining rules on how an end-users interface and functionality of a software should be.
Possibilities for collaboration
Seeing that the ideas of what a user is and can do are very different in common views in open source and in UX design, it is not surprising that people from both disciplines have a hard time working together. Nevertheless, some things might make collaboration easier:
Interface guidelines 4: Guidelines of how interfaces should be designed—both in terms of code and end user appearance and behavior—helps both programmers and designers. Designers know what can be done and conflicting ideas can be sorted out to a hopefully coherent outcome using the guidelines.
Design Systems/Atomic Design: Design Systems and Atomic Design are similar to interface guidelines. However, while guidelines mainly describe with text and images, design systems are often presented as collection of elements and their suggested combinations. Frequently they are created based on code. Designers create the design system, programmers code its representation, both this representation. Ideally, they now know better what each side needs and can do in practice.
User facing extension mechanisms: While the command line deals gracefully with combining very different applications and their parts, graphical user interfaces easily become a mess when different things are added, intertwined with other functions and thus hard to remove. One way of allowing experimentation while keeping the application useful and usable to a large part of users is a mechanism of extending the core software. Firefox is an example for a software doing this since a long time.
However, all these mechanisms need to be defined by a person or a small group who sees both the advantages of the cathedral and the bazaar and can create a community around it in which both cultures feel welcome and collaborate with each other.
Addition 2019-09-22: The open source unity of creator and user is similar to use and creation in bricolage where “Creation and use cannot be dissociated” (Duymedjian, Rüling, 2010)5 – whereas the design practice under the assumption “you are not the user” matches the opposite ideal type to the bricoleur, the engineer (which is somewhat paradox considering that often design and engineering are frames as opposites and that engineering and programming are often seen as closely related). The original idea of the bricoleur/engineer types is from Levi-Strauss’ work, “The Savage Mind”6
Addition 2019-11-18: The self-organization “bazaar” model is closely related to a principle called “stigmergy”, in which the work and the environment created by it hints to how work should be distributed. Bolici et.al.7 describe this in relation to open source software, a comprehensive discussion of the principles of stigmergy is given by Heylighen 8
Changes 2020-01-22: Fixed spelling mistakes
Addition 2020-01-30: Christiane Floyd’s Wikipedia article describes Participatory Design as precursor to the open source movement. It seems natural that participative is connected to the self-empowered individual’s participation in open source projects. Participatory Design, however, rarely refers to a unity of programmer and user. Participatory Design also does not assume that tasks and roles “emerge”: In Participatory Design different skills, roles and power relations between designers, programmers and users are relevant. Also, communication and getting to know each others skills plays an important role in participatory design10. Open Source’s alleged “do-ocracy”, in which power and representation is granted to the people who contribute code is very different from Participatory Design’s concern for representation of stakeholders and making voices of different groups heard. In contrast to open source’s strong influence of libertarianism, Participatory Design is politically left-leaning; Scandinavian Participatory Design originated in “a partnership between academics and trade unions”. 9.
Addition 2020-02-06: I wrote “The bazaar model favors … modularity”. Duguid11 points out that modularity might be quality of software which does not well transfer to other domains of peer production. One particular problem in non-software projects is, that consistency is hard to achieve (e,g, adding sentences to Wikipedia articles easily makes them hard to read) and sometimes people need to work against the suggested way of splitting up tasks to balance out infrastructural needs and a good representation (e.g. If a music metadata-database like Gracenote assumes works come on one medium, how do you catalog a multi disk sets?)
Addition 2020-02-17: Another contrast that comes into mind is that design works a lot with abstractions mobile representations: Personas for users, scenarios for usage, mockups for the final interfaces. Same for management: They have KPIs, Goals, Metrics… However, in an an context organized by stigmergic principles, in which code binds and mediates between creators 7, such representations might be less needed. They might even openly opposed. This could be because they shift power away from programmer/creators but also since they are not seen as useful for programmers/creators.
Addition 2020-04-14: Donald Norman, a well known UX designer and cognitive scientists, wrote about “The trouble with UNIX: The user interface is horrid”. That article includes an rebuttal by Michael Lesk, who worked on Unix. Lesk writes: “A large number of Prof. Norman’s comments are pleas for consistency. Unix has grown more than it has been built…The ability of the system to accept commands so easily is one of its main strengths […] The thought of a UNIX Command Standardization Committee trying to impose rules on names is a frightening alternative. Much of the attractiveness of UNIX derives from its hospitality to new commands and features. This has also meant a diversity of names and styles. To some of us this diversity is attractive, while to others the diversity is frustrating…” While 1981 Linux did not exist and Unix being a commercial system, Norman’s criticism and Lesk’s answer match the different priorities of UX design and open source development: While Norman calls for consistency for the user (which implies planning and coordination), Lesk fears constraints, politics (“Committee”) and lack of adaptability – the concerns of the engineer/creator.
Addition 2021-03-12: I above, I focused on “you are not the user” statements by different authors. But it can be aesthetically more pleasing to compare two text as seminal works for their respective disciplines. So if you rather like to think of it in terms of comparing Raymond’s The Cathedral and the Bazaar and Norman’s The Design of Everyday Things you could also do that and use the following quotes from the book:
- “…In their work, designers often become expert with the device… Users are often expert at the task…” (p156)
- “Design teams really need vocal advocates for the people who will ultimately use the interface” because [Creators] “tend to simplify their own lives.” (p156)
- The only way to find out is to test the designs on users-people as similar to the eventual purchaser of the product as possible. p156
Which are all from one page of The Design of Everyday Things which focuses on the difference between user and creator. (Norman, Don. The Design of Everyday Things. Reprint. Perseus Books, 2002.)
Cathedral and bazaar are useful metaphors. Interestingly, though, early cathedrals have probably been build without plans and architect: Turnbull, David. 1997. “Reframing Science and Other Local Knowledge Traditions.” Futures 29 (6): 551–62. ↩
The idea of emergence of a ‘good’ outcome based on actions of ‘self-fulfilled individuals’ reminds of libertarian capitalism, and technology culture has some overlap with it. See Barbrook, Richard, and Andy Cameron. 1996. “The Californian Ideology.” Science as Culture 6 (1): 44–72 for a general treatment, Tkacz, Nathaniel. 2014. Wikipedia and the Politics of Openness. Chicago ; London: University of Chicago Press for a view on the overlaps of ideas of libertarian capitalism in relation to Wikipedia. ↩
Duymedjian, Raffi, and Charles-Clemens Rüling. 2010. “Towards a Foundation of Bricolage in Organization and Management Theory.” Organization Studies 31 (2): 133–51. https://doi.org/10.1177/0170840609347051. ↩
Levi-Strauss, Claude. 1968. The Savage Mind. Chicago: University Of Chicago Press. ↩
Bolici, Francesco, James Howison, und Kevin Crowston. 2016. „Stigmergic coordination in FLOSS development teams: Integrating explicit and implicit mechanisms“. Cognitive Systems Research, Special Issue of Cognitive Systems Research – Human-Human Stigmergy, 38 (Juni): 14–22. https://doi.org/10.1016/j.cogsys.2015.12.003. ↩↩
Heylighen, Francis. 2015. „Stigmergy as a Universal Coordination Mechanism: components, varieties and applications“. Human Stigmergy: Theoretical Developments and New Applications; Springer: New York, NY, USA. ↩
Spinuzzi, Clay. 2005. „The methodology of participatory design“. Technical communication 52 (2): 163–74. ↩
Ehn, Pelle. 1988. „Playing the language-games of design and use-on skill and participation“. In ACM SIGOIS Bulletin, 9:142–57. ACM. ↩
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. ↩