The road to opaque software is paved with good (engineering) intentions

Tomas Petricek

29 October 2026

Most software we use today is black-box and cannot be easily modified by its users. This article follows the history of information hiding from OS/360 to Free Software and the history of the Web and documents how software becomes opaque through well-intended engineering decisions.

This essay is work-in-progress, currently under submission to an academic journal on history and philosophy of computing. If you have any suggestions, comments or corrections, please get in touch!

When I was writing my first JavaScript scripts at the end of the 1990s, you could learn by finding a web page that did what you wanted, clicking "View source" and copying the bits of JavaScript that you needed. This was surely due to the primitive nature of the web (and what I was trying to do), but the kind of openness that lets you explore, learn, and modify software has largely been lost (in most professional programming contexts) today.

You might argue I'm just nostalgic. After all, open-source has became the dominant development methodology and so users can, in fact, understand and modify a lot of the software they use. But I do not think open-source is the answer. The software freedoms may exist in theory, but in practice, even professional programmers have a hard time modifying complex software systems that we rely on today.

This article is an attempt to understand how software becomes opaque and why. The conclusion, supported by two historical case studies, is that opacity comes about due to good engineering and managerial intentions. Knowing this may help us imagine a better, more open nature of software for the future.

• An earlier blog post behind some of the ideas.
• The essay is also available as a PDF.
• Share your thoughts with @tomasp.net or tomas@tomasp.net.

Table of Contents

1. Introduction

Most software that is built today is a black box. What the users of the software can do is determined by the software design and the decisions of its designers and programmers remain hidden in the program source code. In most cases, users do not have access to the source code.11 A typical situation with online services and apps including, for example, social networks and AI chatbots. Even when the source code is available,22 In case of open-source software such as the Linux operating system, the Firefox web browser or the LibreOffice office suite. its complexity and structure makes it practically impossible for most users to answer questions about the inner workings of the software.

The black box nature of software has wide-ranging consequences. It means that end-users have no way of finding out why they are seeing particular results when using the software and how those results were obtained. For example, they cannot find out why they are seeing a specific advertisement on social media and they have no way of adapting software to suit their accessibility needs. There are numerous attempts to address those limitations. Work on explainable AI33 See for example review by Dwivedi et al. (2023). aims to make artificial intelligence models more transparent, enabling architecture44 Clark (2014) imagines Global Public Inclusive Infrastructure that enables personal digital inclusion. supports building of inclusive adaptable applications and malleable software55 Abstractly characterised by Tchernavskij (2019) and illustrated for example by Wildcard (Litt et al., 2020). empowers end-users to modify their software. Despite the virtuous aims of these approaches, they are treating merely the symptoms of a more basic limitation of our present way of engaging with software.

Our relationship with software resembles the troublesome relationship of the society with technical objects that has been studied by Gilbert Simondon in the 1950s.66 His thesis On the Mode of Existence of Technical Objects was published in French in 1958, but the first official English translation only appeared in 2017 (Simondon, 2017). Simondon examined the sources of alienation, arguing that the “most powerful cause of alienation in the contemporary world resides in this misunderstanding of the machine, (...) by the non-knowledge of its nature and its essence.”77 Simondon (2017, p.16) Today, when software is increasingly ingrained in a wide range of aspects of our lives, and our “non-knowledge of its nature and its essence” is ubiquitous, the “most powerful cause of alienation in the contemporary world” may well be the misunderstanding of software. At a time when the society needs to make important decisions about software, the opacity of software prevents us from developing an effective conceptual framework for understanding how software operates. The fact that most software is intentionally built to hide its inner workings is a crucial part of that. As Simondon pointed out already, the “technical objects that produce the greatest alienation are those meant for ignorant users.”88 Simondon (2017, p.255)

The opaque nature of software is not a necessity. The history of programming offers many visions of a more open software. The Free Software movement envisioned software that gives users the freedom to “study how [it] works and adapt it to [their] needs,”99 This particular wording is from the “What is Free Software?” page published on the GNU website in 1997 (Free Software Foundation, 1997), but similar ideas already appear in the first bulletin of the Free Software Foundation (Stallman, 1986). while the creators of the Smalltalk programming language in the 1970s saw their system as “a general purpose meta-medium that anyone can adapt to their particular needs.”1010 Quoted from Kay and Goldberg (1977). The language itself has been described by Goldberg and Robson (1983). See also historical reflections by Kay (1993). Such software could empower users to engage more closely with software and, possibly, also help develop a better understanding of software in the broader society. Yet, despite these appealing visions, often backed by solid engineering developments, opaque software remains the norm.

Understanding how software becomes opaque is the necessary prerequisite for undoing the closing of software. As argued by Federica Frabetti, if we want to tackle the deep opacity1111 Frabetti (2014) adopts the term used by Stiegler (1998) who maintains that “we do not immediately understand what is being played out in technics (...) even though we unceasingly have to make decisions regarding technics the consequences of which are felt to escape us more and more.” of software, we need “to problemaitize the intertwining of the technical and the social aspects of software”1212 Frabetti (2014, p.xix) and question “the conceptual system on which [software] relies for its functioning.”1313 Frabetti (2014, p.xiii) Frabetti does this by critically interrogating “historical-cultural and technical narratives,” including the origins of software engineering and reflections on free and open software. I follow a more historical approach. Taking inspiration from the methodology of critical software studies,1414 The book edited by Fuller (2008) introduces the field; specific approaches include critical code studies (Marino, 2020), studies of singular artifacts such as a BASIC one-liner interrogated by Montfort et al. (2012) or rethinking of the history and origins of software (Sack, 2019). I closely examine two specific historical case studies (§4 and §5) and use them to document how decisions regarding software opacity are made. Before doing so, I review notable past visions of open software (§2) and classify the different notions of software openness that appear in this article (§3).

2. Visions of open software

Multiple past visions of software included openness as their key component. Many of those visions had a profound impact on the computing industry, but in a remarkable number of cases, the idea of a more open software later got lost.1515 This review is inevitably incomplete. Many more systems would deserve a mention, including Boxer (diSessa and Abelson, 1986), Lisp Machines, Interlisp (Steele and Gabriel, 1996) and Emacs (Stallman, 1981).

Figure 1. Smalltalk 78 running the SimKit demo in an emulator by Computer History Museum (https://smalltalkzoo.computerhistory.org/). The simulation in the background models office scheduling task. The Browser in front allows the user to explore how the simulation is implemented.

2.1 Smalltalk

The Smalltalk programming language was envisioned as the software side of the Dynabook, a “personal dynamic medium the size of a notebook which [could] handle virtually all of its owner's information-related needs.”1616 Kay and Goldberg (1977) The language was intended as “a general purpose meta-medium that anyone can adapt to their particular needs.” This means that a “kid may turn [the Dynabook] into a painting system, a musician may turn it into an audio synthesis system and a decision theorist can turn it into an agent-based simulation system.”1717 Petricek (2025)

Openness was a necessary part of the vision, because it enabled users understand how the system works and learn how to modify it:1818 This idea was illustrated in an article presenting Smalltalk in the 1981 issue of the BYTE magazine (Reenskaug, 1981).

The new user of a Smalltalk system is likely to begin by using its ready-made application systems for writing and illustrating documents, for designing aircraft wings, for doing homework, for searching through old court decisions, for composing music, or whatever.

After a while, he may become curious as to how his system works. He should then be able to “open up” the application object on the screen to see its component parts and to find out how they work together.

The next thing the user might want to do is to build new systems similar to the one he has been using. A kit of graphical building blocks would let the user compose a new system (...). Finally, the expert user would want to make his own kits.

Today, Smalltalk is recognized as the first object-oriented programming language. Object-oriented languages like Java adopted many of the Smalltalk language features, but not the openness of the medium. If you have a running Java application, you cannot “open it up” to find out how it works and adapt it.1919 Although the iPad has the form-factor of the Dynabook that Alan Kay envisioned in the 1970s, Kay criticised its closed nature arguing that iPad “could not be farther from the original intention” (Greelish, 2013).

The development through which the open object-orientation of Smalltalk turned into the closed object-orientation of Java has been described as the shift from the humanistic to the engineering culture of programming.2020 (Petricek, 2025) While the former emphasized openness as a value, the latter was concerned with practical engineering issues such as deployment, which was challenging in the original Smalltalk model.2121 The issues with deployment have been listed as one of the possible reasons for the demise of Smalltalk (Bracha, 2020).

2.2 Microcomputers

In the 1970s, Smalltalk required an expensive special-purpose hardware that was only available at Xerox PARC. What made computers more widely accessible was a parallel development.2222 This common narrative has been questioned by Rankin (2018), who points out that access to microcomputers was still limited to an elite group and that there were other computer networks based on time-sharing systems at the same time. Microcomputers were a new kind of computers enabled by the development of microprocessors.2323 Advertised as “computer on a chip”. At first, microcomputers were toys for highly technical tinkerers, but they soon became more powerful and user-friendly.

The “1977 trinity,”2424 The term “1977 trinity” only appeared in later written retrospectives. A detailed account of the history of microcomputers has been written by Haigh and Ceruzzi (2021). comprising Commodore PET, Apple II and TRS-80 sold millions of units. The way these microcomputers worked was remarkably close to Alan Kay's vision.2525 Petricek (2025) The machines booted into an interactive BASIC programming prompt and even playing a game involved typing program commands. The code of BASIC programs was accessible to modification and was often copied line-by-line from magazines, exposing regular computer users to programming.2626 Inspired by the complementary science methodology (Chang, 2004), the web-based Commodore 64 BASIC reconstruction (https://tomasp.net/commodore64) documents interesting ways of working of the system that have been lost.

The early open spirit of microcomputers did not last. Developers started creating more sophisticated applications for microcomputers and many of those were not coded in BASIC, but in low-level and more opaque assembly. This was frequently for performance reasons. Many microcomputer users also stopped thinking about them as general-purpose programmable systems, but as devices to run a specific application. As documented by Laine Nooney,2727 Nooney (2023) the Wall Street users referred to Apple II as the “VisiCalc machine,” using the name of an early spreadsheet application, their primary reason for buying the computer.

2.3 Free software

A