Small software and the costs of scaling

Date Tags theory / community / design / UX

Recently, I browsed itch.io’s tools section, a list of many tools, largely for game creation or general computer-supported creativity: Musik, zines, map generators, and batch tools. They remind me of late 90s and early 2000s free- and shareware: Small, useful tools created often by single programmers, sometimes a bit clunky to use, but always with some sort of user interface that does feel like it wants me to work with it.

What is special about these tools is that they often succeed with something seems to be very difficult for a lot of open source projects: Providing a user interface that non-programmers like to use.

A common explanation for the difficulty to provide a good user experience in open source software products are:

  • the lack of resources to hire UX designers for the open source projects
  • the lack of motivation of UX designers to volunteer to work on open source projects.

Both explanations satisfy UX designers and open source programmers: The UX designers, since their work is seen as required for a good user experience, and the open source developers, because its not their fault that neither money nor UX designer motivation is there.

However, applications on itch.io seem often created by single people or small teams of collaborators and they often have enjoyable and usable interfaces. Creating such an interface thus does not seem to require hiring a UX designer as a separate role in your project.

The difference to many open source software projects partly lies in the value structures of the different communities. Open source software is build on the idea of a community organizing around the code of a software 1. However, for tools on itch.io, the usefulness and joy for non-programmer users are important, since only some community members are programmers. This makes the software on itch.io similar to the free- and shareware of the 90s and late 2000. Specifically, software on itch.io is usually aimed at game creators and other way to be creative with computer which can include coding but also many other activities. Code is not the core thing and value to organize around.

UX involvement is not concerned with code. However, it usually assumes team of experts, with clearly distinguished roles, collaborating together – e.g. managers, designers, researchers and programmers. Such teams usually work in a larger organizations that both require and can afford teams of professionals. The user in this context is both very important and strangely absent: User involvement is mediated through UX research methods and representations that can be moved through the organization efficiently and discussed with management and developers: A pdf with a user representation (e.g. as persona) can be send around in a mail attachment, the actual user could not.

Both the ideal type of open source development and UX design work apply to large scale collaborations. They tackle the the problem of scale in different ways:

  • Open Source development by focusing on code and pay for this by losing sight of the non-programmer user.
  • UX design by standardization and representation through expert roles and pay for this with the need for expert roles and by abstracting the user.

However, not all software needs to be large scale. Most tools on itch.io are rather small. Since single people or small teams work on such software, they neither need to use complex, abstraction-based UX processes to ensure coherence towards users, nor do they need to group their concerns around code to be able to scale outside of an organizational bureaucracy.

For software that people like to use, following the best practices of Open Source development or UX design might sometimes be detrimental: They both come with a lot of overhead to enable their specific models of scaling which might be not beneficial to create small scale, end-user friendly software as a hobby project. Best practices are always bound to a context like market model, technology and collaboration and competition with fellow professions—and if your context is different the best practices might just be good practices for someone else.

Related Posts

Notes:

  • “Lessons learned from 15 years of SumatraPDF” – a software that is open source, but “a side project, done after hours”. It has some interesting sections that deal with which practices are helpful for SumatraPDFs creator: “act as if it was a commercial product from a software company" as well as the reasons why the creator does not focus on code reviews and tests.
  • Scale and Coherence as a problem of software creation was already discussed in Fred Brooks’ “The Mythical Man-Month” (1975). The problem of scale is basically the book’s core idea (“Adding manpower to a late software project makes it later”); For achieving coherence, the author suggests a single or a few chief architects for the system who ensure its conceptual integrity: Clearly more Cathedral than Bazaar.
  • 2023-07-14: Alspaugh/Scacchi’s “Ongoing software development without classical requirements” 2 is related, but focuses on open source software rather than (as I did here) on small software projects.
  • 2023-08-01: Related resources: An app can be a home-cooked meal (programming should be professional but home cooking does not need to be: “When you liberate programming from the requirement to be professional and scalable, it becomes a different activity altogether”), Situated Software; on the idea of the “small web”: rediscovering the small web, the small web is beautiful, what is the small web
  • 2023-10-08: We can build these ideas into a trilemma, in which one can have only two of three things: scale, cross-professional collaboration or self-organization (with their inverse being small teams, management/bureaucracy and homogeneity) a triangle with the tips being labled scale/cross-professional collaboration/self-organization
  • 2023-11-04: Changed the title from “Software on itch.io and the costs of scaling” to “Small software and the costs of scaling”, while browsing itch itch.io helpt to develop the idea, the article is not so much about the platform itself.

  1. The open source model seems to work specifically well for code. Code itself can serve as both object of work and for the work’s coordination 3. Code can also be well modularized. However, modularization can be problematic for many non-code projects 4, particularly artistic works 5. ↩

  2. Alspaugh, Thomas A., and Walt Scacchi. 2013. “Ongoing Software Development without Classical Requirements.” In 2013 21st IEEE International Requirements Engineering Conference (RE), 165–74. Rio de Janeiro-RJ, Brazil: IEEE. https://doi.org/10.1109/RE.2013.6636716. ↩

  3. Bolici, Francesco, James Howison, and 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 (June): 14–22. https://doi.org/10.1016/j.cogsys.2015.12.003. ↩

  4. 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. ↩

  5. Hill, Benjamin Mako, and 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. ↩