I'd like to think about disintermediation for a second. Or not. Why not think about disintermediation? Maybe saying I'm not thinking about disintermediation is wrong. What I really mean is that, rather than just thinking about disintermediation, it's a matter of thinking about who the disintermediation is for. Because it's tricky. I mean, the classic sense of the concept implies that there's a producer and a consumer, and often there's a middleman, but disintermediation takes away the middleman, allowing the producer and the consumer to trade directly.
Let's take two of my cases and apply the classic idea of disintermediation to them. With F/LOSS, I'll grant, if we choose to uphold the producer-consumer dichotomy, then yes, there's often disintermediation. There's every project having its own website/IRC channel/mailing list/whatever. But what's interesting is that there's also a re-intermediation happening. When a project packages its software for a distro, that's re-intermediation. The distro and its package manager are a middleman. And projects do that packaging so that more people have access to their software. Because it's easier to install something when it's packaged for the environment you're running. You avoid things like dependency hell. So that's kind of interesting. In a lot of cases, F/LOSS, which is arguably born disintermediated, is re-intermediated for maybe the vast majority of its consumers. But then it's profoundly disintermediated for some others, as people do things like join mailing lists, install nightly builds, or just download it directly from the project website. But many of these activities imply that people are going beyond mere consumption. They're becoming community members or even taking part in development. So it may actually be that F/LOSS doesn't so much disintermediate as break down the distinction between producer and consumer. Which is a very different thing. Where disintermediation reifies the distinction between producer and consumer, community-based production practices break down that distinction.
If we look at the prosthetics project instead, we see a process that has never really been intermediated. The person building the prosthetic has always been in direct contact with the person getting the prosthetic. There's nothing that needs to be disintermediated. On the other hand, if used wrong, the digital process could intermediate things. In fact, an intermediation is one of the things we need to consciously avoid. We're trying to avoid turning the Ugandan medical practitioners into an intermediary between a patient and a skilled prosthetist in the West. If we look at some genres of telehealth work, maybe we'll see that kind of intermediation. Someone on the ground who's less skilled at a particular task, and someone more skilled at a distance, with the less skilled person implementing the advice and instructions of the distant expert.
Let's take two of my cases and apply the classic idea of disintermediation to them. With F/LOSS, I'll grant, if we choose to uphold the producer-consumer dichotomy, then yes, there's often disintermediation. There's every project having its own website/IRC channel/mailing list/whatever. But what's interesting is that there's also a re-intermediation happening. When a project packages its software for a distro, that's re-intermediation. The distro and its package manager are a middleman. And projects do that packaging so that more people have access to their software. Because it's easier to install something when it's packaged for the environment you're running. You avoid things like dependency hell. So that's kind of interesting. In a lot of cases, F/LOSS, which is arguably born disintermediated, is re-intermediated for maybe the vast majority of its consumers. But then it's profoundly disintermediated for some others, as people do things like join mailing lists, install nightly builds, or just download it directly from the project website. But many of these activities imply that people are going beyond mere consumption. They're becoming community members or even taking part in development. So it may actually be that F/LOSS doesn't so much disintermediate as break down the distinction between producer and consumer. Which is a very different thing. Where disintermediation reifies the distinction between producer and consumer, community-based production practices break down that distinction.
If we look at the prosthetics project instead, we see a process that has never really been intermediated. The person building the prosthetic has always been in direct contact with the person getting the prosthetic. There's nothing that needs to be disintermediated. On the other hand, if used wrong, the digital process could intermediate things. In fact, an intermediation is one of the things we need to consciously avoid. We're trying to avoid turning the Ugandan medical practitioners into an intermediary between a patient and a skilled prosthetist in the West. If we look at some genres of telehealth work, maybe we'll see that kind of intermediation. Someone on the ground who's less skilled at a particular task, and someone more skilled at a distance, with the less skilled person implementing the advice and instructions of the distant expert.