Instability, Risk, And The Digital Supply Chain

I've previously written about a division of labour in software development. This concept is relevant for the tools we use to write our plans, to convert our plans (that include an explicitly declared supply chain) into digital experiences, to distribute our digital experiences to customers, running an app, testing an app and distributing an app.

When software professionals start the work of producing software, we begin with a particular goal in mind. We produce a solution and often we find that after handing it to other people one or more of the following happens:

• The way our users think it should be operated differs from how we intended for it to be operated - we see our solution differently from how our users see our solution.
• That there are problems that we had not previously considered - we see the problem space differently from how our users see the problem space.

So from some iterative process of reconciliation, the software changes over time with the goal of improvement. In real-world production it is common as this happens that the plans - the production processes, the machinery and the supply chain - evolve. Early in the lifecycle of a project, the production processes encoded in our plans largely emerge from specifications of what the software must achieve, and the machines and the supply chain come from some combination of:

• Skillset of the project team, including experience.
• Available third-party solutions (fitting within an existing context of locked-in technology choices)
• Time
• Budget
• Compliance requirements
• Performance of the existing software as measured by various code metrics, which change as our plans evolve change.

In our plans we generally externalise as much of our production processes as we can, with the expectation that we will benefit from a centralisation of effort - and we do typically do this by exploiting the open-source software community. The open-source software community is a network of people that may work for large technology companies, may work for smaller companies, may be hobbyists or students. One way or another, they have found it to be in their interest to contribute toward some centralisation of effort, frequently for zero financial reward. Additionally, there is no natural alignment between the needs of a given software project and the third-party solutions that commercial markets have to offer.

Software projects frequently outgrow third-party solutions and are forced to either look for alternatives or take greater ownership of production processes over time. This can happen for many reasons - the authoring individual or company may no longer maintain the solution or it may have critical bugs (another instance of altering the deal), the project may require greater control over functionality than third-party solutions provide, cost reduction, and more. Third-party solutions when they are available are often not homogenous in their offering, and switching often results in adjustments in the division of labour. Even if we do not have to take full-ownership of this part of the value chain, more often than not we have to take more responsibility than we previously had. This is another source of the phenomenon of commoditisation, or lack thereof.

While we are discussing risks it is worth understanding that while our project is software, our supply chain is also comprised of other software, and consequently face the same challenges that our software projects face, such as the baked-in problems pertaining to code and quality metrics. They are changed over time, and any change carries some level of risk to our project - we often expect tools in many professions to be stable (a hammer isn't automatically updated with a breaking change overnight, leaving us unable to use it the follow day) although those of us who work in corporate office environments probably have some exposure to this problem.

So we have established that for some time there have been challenges of alignment due in part to the absence of warranties and profit exchange, and also due to the same problems that exist in software in situations where we largely have control over the value chain. Now we can move on to some more recent concerns.

In the last few years there have been layoffs in the magnitude of (at minimum) tens of thousands (if not hundreds of thousands of layoffs) at big technology companies. There has also been a large shift of allocation of resources toward projects pertaining to large language models and other "AI" software projects. Each of these on their own represent significant supply shocks to the global digital supply chain, but it doesn't end there as the adoption of LLMs has shaped the way that code is written for many projects. The writing of code was already a complicated navigation of distinct tradeoffs that relied on, in-part, stable platforms, for the development of instincts on how to make those tradeoffs, and now these platforms seem less stable than they have been for years, although it would likely be an exaggeration to say that they are less stable than ever.

If you start a software project today and start writing code without the assistance of large language models, you almost certainly will end up with an second-party or third-party dependency on code that has been at least partially shaped by large language models. This is effectively another manifestation of altering the deal.

If you were interested in opting-out of this movement, to attempt to do so would prove very difficult. AI-produced code is in operating systems, in tools, in apps, in the cloud. It is still too early to say that we fully understand how digital supply chains will have changed compared to the "before-time" when LLMs had yet to be popularised, yet I think it is clear enough that these changes present risks to all software produced worldwide.

We will probably see changes in the characteristics of many open-source projects based on biases in publicly available code. I think we will see concerns related to ownership and access rights as increasingly influential forces in the global digital supply chain. One possible future is that we see a total erosion of open-source as we know it. A less extreme version is that there is a re-evaluation of what it means to be a contributor, which probably eventuates in more altering of the deal as many former contributors consider whether it is a worthwhile pursuit. It's not necessarily a net exodus, but any inflow of people could have different sensibilities and past experiences which we can reasonably expect will shape the centralisation of effort. One person leaving a software project of consequence can be consequential over a long enough timescale. The scale of change we have seen in recent years is hard to truly comprehend.

Digital supply chains are much more important, and more fragile than most people understand, and I think they represent one of the more insightful parts of the model of software as digital manufacturing. I believe we will see many more shocks in our future, and perhaps in unexpected ways and sooner than we think. Hold on to your hats.

Until next time.