Paper by basman, ptchernavskij (2018)
We argue that a form of “digital serfdom” has rapidly grown up around us, where various important classes of artefacts, increasingly essential for everyday life, including participation in political and economic life, cannot be effectively owned by ordinary individuals.
Many of the technological barriers to ownership, especially as regards software, can be seen as embedded in certain questions of “reuse” — one of the central affordances of ownership is the ability to transplant a thing from its original location to a different one, following the desires or person of the owner. For most kinds of software this is possible in only a crude way — an “application” can be installed on one machine rather than another — and with the rising prevalence of rental or cloud-based models for the deployment of software, it is decreasingly possible at all.
If you find a piece of software that does something of value to you, it should be possible to make it your own. This implies that you can keep using it as part of the collection of tools you carry with you, in familiar contexts, or experiment with using it in novel contexts.
- suggesters: jryans
- curators: jryans
In a delicious piece of irony, when I click today (November 2023) on that PDF in order to make it my own and read it, I get a “Server Not Found” message. The client-server-based architecture of the World Wide Web has demonstrated exactly the problem that the author is (presumably, since I can’t read the paper) complaining about.
Here’s another link to it. I remember really liking this paper when I read it a few years ago.
Nice paper, thanks for posting! “Ownable” is an interesting perspective, actually closer to what I care about than “malleable”.
(The question of course is what “owning” or “property” means. What stuff should you be able to do with it to be able to say you own it? I think the concept of malleability offers greater precision, and helps us have more effective conversations about sense of ownership.)
“Owning” is about rights and values, “malleable” is about technical characteristics. So, yes, the latter is more precise, and certainly a better concept to organize discussions around. But what I care about, and what I argue for when talking to others, is the core value behind it.
Thanks for sharing an updated link, not sure what may have happened to Tchernavskij’s site…
I’ll update the wiki entry / top post to use the version in Basman’s repo, which lists both authors.
It’s quite an interesting and thought-provoking paper, agreed!
What you own is to experience the work in the way the creators intended for their audiences, and malleability gives you the opportunity to adapt it for yourself and your audiences.
Interesting to consider how the tools used are a kind of “man-in-the-middle” and how that might influence that ownership relation.
Consider hypothetically how a “one-stop-shop” future Github might host iNaturalist on Azure and facilitate commenting in the UI that is cross-linked to that PDF paper and stored as issues in the repo’s tracker. Very convenient tool, but now GH has its claws deeply into the work as a co-owner, and is encroaching further with every feature it adds to its platform.
Update: Cross-ref to Making networked software our own by @akkartik appropriate.
Every piece of software is a plug-in for a larger system. Today’s iNaturalist is a plug-in for a system consisting of a development infrastructure and a Web server, the two being almost independent, and controlled by different entities. Your imagined future GitHub would combine the two into a single integrated platform under the control of Microsoft. I am pretty sure that Microsoft is already working on this fusion.
The two lessons I see are:
Merging development and deployment platforms is very convenient for the creation of malleable systems. But then, that’s hardly news: it was well-known in the 1980s, from Smalltalk and Lisp.
If you want to retain control over your software, you can’t depend on a platform controlled by somebody else. That’s where we don’t have a good solution for now. Platforms of this kind should be managed as commons, but we don’t know how to do that yet. FLOSS is merely a first step.