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 3.
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 is often preferable, 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 4 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 5: 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. ^[cathedralCore]
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.
- Logo Competitions in Open Source Software Projects on the social functions of logos aside/instead of being a ‘good logo’ according to professional judgment.
- Collaboration without shared professional culture Some theory on cross-disciplinary collaboration and why it is useful that designers don’t work like developers.
- On violating the standards of one’s occupation about the uses of having “usual ways to act” in a profession.
- Small software and the costs of scaling suggesting that both open source and UX design tackle a problem of scale, which open source solves by everyone being a developer and UX design by a professional bureaucracy of result documents (“deliverables”)
- 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)8 – 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 framed 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”9
- 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.10 describe this in relation to open source software, a comprehensive discussion of the principles of stigmergy is given by Heylighen 11
- 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 design13. 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”. 12.
- Addition 2020-02-06: I wrote “The bazaar model favors … modularity”. Duguid14 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 10, 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.
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.)
- Addition 2022-11-18: I find it interesting that both User Experience Design and Open Source culture have a connection to artificial intelligence research: Early Human Computer Interaction researchers Newell, Card, and Moran worked with cognitive modelling like GOMS; Newell founded the artificial intelligence lab at CMU. Hacker culture relates strongly to the MIT artificial intelligence lab; Unix was also co-created by researchers at the MIT, but I do not know if there was collaboration between the AI Lab and the people working on Unix.
- Addition 2023-03-28: Added a reference to Kjeld Schmidt’s observation that lot of influential interactive systems being invented by users for users.
- Addition: 2023-03-02: The designers focus on coherence (see comment on Unix and Donald Norman, 2020-04-14) is not only a concern for UX designers but also for software designers. Brook’s “The mythical Man-Month” discusses “conceptual integrity” of system architecture at length (and also has a brief section on cathedrals!). This is actually not in conflict with Raymond’s claims who talks about the needs to start with “strong, attractive basic designs”. To have “conceptual integrity” of user interfaces seems to be secondary in many open source projects—not so surprising when focussing on building a community developers.
- Addition: 2023-03-03 Related to the comment from 2023-03-28: This seems how a lot of software on https://itch.io/tools is created; feels very 90s freeware/shareware and focused on end-users. They don’t do what Open Source communities find important (only some projects have formally open licenses) nor what UX designers find important (probably don't follow formal UX design processes or formal research).
- Addition: 2023-10-14: Both communities are also divided by their choice of tools; designers using drawing tools with direct manipulation, whereas open source software focuses on plain text. (Both communities, however do secondary work in communicating about their work in “deliverables” or “issues”). The plain text focus of open source/hacker culture goes together with its love for Unix and C. The plain-text focus is not universal for all programming; Smalltalk is still written in plain text, but is bound to an runtime environment that serves as development tool and (non-plain-text) storage format; not coincidentally, Smalltalk was a huge influence on the Xerox Alto and early GUIs.
- Change: 2023-11-04: Corrected a spelling mistake, put the Notes in a list, added related articles.
- Addition: 2024-02-01: Footnote on Raymond on “a cathedral-mode core and a bazaar-mode toolbox.”
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. ↩
Rejecting “designing for oneself” and the idea that design is/should be based on academic disciplines is probably best understood as a part of the struggle of designers to legitimize their discipline. A lot of systems influential in the history of UX design and human computer interaction were designed by users for themselves7. ↩
User-facing extension mechanisms are a variant of what Raymond calls “a two-tier user community that combined a cathedral-mode core and a bazaar-mode toolbox.” (source). Raymonds example is MATLAB, a data analysis tool working with user-script-like code; However, an user-facing extension mechanism defines a way how the user interface can be defined and extended, allowing some flexibility in a standardized way to plug new buttons or menu entries in. ↩
Schmidt, Kjeld. "Of humble origins: The practice roots of interactive and collaborative computing." (2015). ↩
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. ↩