Ownership And Access Rights

Ownership and access rights are important companions to the previously discussed division of labour concept in software development. The mobile development space is dominated by two digital software platforms, iOS and Android, which are managed by technology giants Apple and Google respectively.

These platforms are an intermediary between mobile applications and features that have become commonplace such as push notifications, password storage, camera and photo access, and more. Similar to the scenario of a mobile app talking to a computer in the cloud as mentioned in the article about the division of labour, these device features are enabled by a shared protocol, sometimes referred to as a handshake agreement. Occasionally, the platforms alter the deal in their system software updates. When a third-party alters the deal, failures are likely to happen. Let's go back in time to the 1990s for a moment and consider a VHS player. VHS players expect tapes to be inserted into them, and in response they will facilitate the playback of the video that has been recorded onto the tape. As long as a VHS tape is provided and the player is free of defects, the system will meet its obligations. Anyone with children might appreciate what I'm about to say next... Now imagine that a sandwich is inserted into the VHS player instead of a tape. I don't exactly know what happens next but I know that it's nothing good. The handshake agreement has been violated, and now subsequent attempts to play tapes are unlikely to succeed.

The problem is that the machine was designed for a particular input, and no other input is acceptable. Digital machines function on a similar basis, but they do so without the benefit of human beings to directly observe what is going on without a process of investigation. This problem manifests itself in other contexts, but it is pertinent to the issue of ownership as there are production processes embedded in contemporary mobile applications with an enforced division of labour. If you want to publish a software application on iOS, there is some set of machinery that is provided by Apple that must be used, and is not optional, and cannot be replaced, and is effectively substituted in when a particular app session starts. This is one path to a common production story: "I updated my phone and now the app is not working". This class of scenario highlights that mobile software projects have a degree of enforced reactivity baked in to them - to address platform-related issues, we need to perform work in response and release a software update, which may not have been anticipated ahead of time.

Occasionally these issues happen in a domain outside the boundary of what would normally be considered the responsibility of an application developer. As part of a software supply chain, it is common for application developers to use a framework as part of the division of labour in order to solve various computer-specific problems that are quite far away from delivering value to users or a business, e.g. the experience of displaying any kind of video on a device is one that is made possible at least in part by the hardware platform (the physical device) and software that interacts with it (the software platform e.g. iOS, or some part of its own software supply chain). This is a different kind of enforced division of labour that emerges for economic reasons as it is generally not viable for software projects to take ownership of problems that happen at the framework level, and the cost of switching software frameworks can be extremely high. When handshake agreements are violated between a framework and a platform (in either hardware or software) it creates a negative experience for everyone downstream - those working on the project directly (who are not well-placed to address such problems), the business around it, the customers of the business, and any other project and its stakeholders that face the same problem.

The concepts of ownership and access rights are influential opposing forces working against the commoditisation of solutions in code. As code can be represented as text, for many projects it could be possible in principle for someone else to take your project and distribute it as their own if they have access to the code base. Much like most other company property, codebases generally have restricted access, in part for this reason. If you were to scroll through the top 100 apps on the App Store or Play Store and do some research to determine whether their codebases were publicly available you would likely find that it is a very small fraction and perhaps even zero. Restricting access to the codebase through technological or legal means forms a moat against competing projects in the same market, which is likely to be a concern for as long as there is commercialisation of digital software. These closed-source (code) projects contribute to a dynamic where most software projects loosely resemble the Manhattan Project. Technical problems relevant to a particular business goal may have been solved elsewhere in the world by a different group of people working for a different company, but that knowledge is not shared, and may have no mechanism to be shared. This concern heavily shapes answers to the question of what a software developer actually does day-to-day, and is important to the concept of the digital factory.

It is also quite relevant to the current moment, where there are very active discussions among professionals in the field about the use of large language models and from those discussions have emerged a variety of opinions about their utility. My experience has been that their practical utility for a given task is heavily shaped by considerations of commoditisation, ownership and access rights, which we have reasons for expecting will be stable in time. This is still an evolving space, but I have come to form suspicions that having a good understanding of how technology and society interact is important in order to extract value from using this technology.

To ground what I am saying in more specific terms, if I was interested in building a static website and I provided really specific context about what I wanted, I would expect to get good results because I expect that LLMs have a large pool of data related to webpages, how they're structured, and how the structure of code relates to the business value. In contrast, if I was interested in rebuilding Spotify or YouTube, and provided really specific context about what I wanted, I might get something in return, but it is really unlikely that I will end up with a recreation of the Spotify value chain, in part because of concerns of commoditisation, ownership and access rights. Spotify's codebase not public, nor is documentation about the technical implementation. I can also not reasonably expect a large pool of codebases that are Spotify-adjacent to be publicly available (or technical documentation about those) and this is a dynamic that is likely going to be stable in time. I think this has some clear implications about who is well-placed to be using AI and who is not, depending on the place of their project in a software supply chain. Another really important consideration is the primacy of particular code metrics in the data that models are trained on. Real production apps may have performance considerations that are going to be systematically missing from the code and descriptions of that code used in the training dataset. Competition is driving a lack of transparency in the space, which makes it difficult to establish confidence about the data agents are trained on, and how exactly the gaps that exist due to ownership and access concerns are filled, if at all.

Until next time.