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 intestingly 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 than 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 principle is process emphasizes self-organization and positive competition. The single parts 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 to deal 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 a 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.
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. ↩