The Solipsis Project

On AI - Part 4: “The Filler Episode”

2023-03-08T00:00:00+00:00

I toured a house for sale today. A framed art print hung in the living room: a photograph of six horseshoes arranged in a grid. Climbing up the stairs, I was greeted by an abstract painting made of horizontal bands in soft pastel colors. Studying it closely, I imagined I was looking at a beach, but that may have been my imagination projecting its own meaning onto the canvas.

These pieces were placed there by the real estate company, chosen to evoke feelings of coziness while being politically inoffensive. They were purchased from a wholesale home decorator.

Their designs were created by human hands. I found myself wondering about the process of these artists. What techniques did they use? Did they have an artistic vision? Were they commissioned, or did they design the pieces independently and then license them? Did the artists see themselves reflected in these pieces or was it just a job? If there was an artistic intent, it’s now far enough removed from the artist that we can only speculate.

I suspect, although I can’t prove, that the main reason these pieces were made was to meet a demand created by offices and model homes. Generic, mass-produced home art is an entire industry. Its purpose is not to make any artistic statement, but to fill the silence of bare walls with the white noise of color. It’s filler.

“Filler” is a word with a negative connotation. In television, filler episodes pad out the season, meandering to avoid any plot or character developments that would disrupt the status quo. In cooking, it’s material to add bulk to food without adding any nutrients. It takes up space but has no real substance.

And yet, there is an entire industry devoted to the production of “filler” visual art. It is separate from the visual entertainment industry, although it employs the same artists, and draws upon similar talents.

This isn’t a put-down of the industry: I too, have bought art like this. At home, hanging above my office desk is a canvas print of a painting of a deer. I bought the print at IKEA, where it had been mass produced for the express purpose of filling out the walls of new homes. It has thousands of copies; I wouldn’t have been shocked to spy one of its many twins during the house tour.

And yet, I treasure my copy of the print. It reminds me of a friend, and a photograph he showed me once. That evocation of memory is the reason I bought it. The painting is meaningful to me, although it’s a meaning of my own creation. Like the abstract painting aforementioned, I projected my own interpretation onto the piece.

The “filler” industry is real, it’s alive, and it’s made a positive (if minor) impact in my life. And it will be the first to be severely disrupted by modern generative AI tooling.

So let’s talk about it. This is “The Filler Episode.”

Generative AI is, in a certain sense, the artistic equivalent of a “white noise machine.” Its results are incredibly lifelike, but without human guidance and interpretation, they produce little more than a perfectly generic simulacrum of human creation. They generate what is essentially “background” text and images, and invite us to project our own signal onto the noise.

(This is part of why it’s so dangerous to use AI outputs as an authoritative source of knowledge. They don’t just reflect the biases of the training data, they also reflect the biases of the user back at them.)

As I discussed in a previous post about generative AI, when a user projects their own value judgments onto the results and curates them, it becomes possible for that act of curation to produce an output that reflects the user’s artistic intent, and is in that sense, creative. But absent that, what they produce is filler. It takes up space on the canvas, it doesn’t look out of place, but it doesn’t say anything.

But I’m not denigrating filler text; I use it all the time! Oftentimes, when I’m writing a story, I have an outline of important scenes that need to happen and images that I want to describe. Then, I begin the task of writing the sinew that connects these scenes to a single narrative. That process of writing the connective tissue is the most laborious part of my writing process. It is also the least creative. Usually the process of writing this sinew allows me to identify opportunities for additional scenes, so both the story and my personal growth still benefit from writing it. But the writing of these scenes is still boring and mechanical. It’s filler.

It’s the exact kind of writing that generative AI has been shown to excel at. I’m tempted to see if I can get a language model to write those parts for me. Or at least have AI write the first draft which I can then go back and edit, replacing its generic prose with my own voice.

A better writer than me wouldn’t need filler. In fact, the better a writer you are, the less filler you need. A master writer doesn’t just make every word count, they make every word count multiple times. Every sentence is maximally efficient and is dripping with so much authorial intent that no one other than the author could possibly have written it.

For example, one of my favorite written sentences is the opening to Robert Charles Wilson’s Axis:

In the summer of his twelfth year—the summer the stars began to fall from the sky—the boy Isaac discovered that he could tell east from west with his eyes closed.

I love this sentence because of how much work it does. It establishes the main character and gives him not only a name and age, but also a disposition: he’s curious, observant, and experimental. It establishes the story’s place in the world’s chronology (“the summer the stars began to fall from the sky”), while simultaneously creating a sense of mystery and arousing the reader’s curiosity. And it documents the incident that kicks off the story’s plot: Isaac’s discovery of his unique ability, and the investigation of its underlying cause. It’s not a long sentence, but it pulls so much weight.

It’s a sentence that not only has a clear authorial throughline, but it’s a throughline that is consistent with the remainder of the work in which it appears. And there’s no filler: each word is in service of this intent. These are qualities that can’t be generated even by ChatGPT. (Or at least, making ChatGPT generate a sentence like this would require so much interactivity from the user, so much editing of prompts and curating of responses, that the output is more a reflection of the user than the model. In neither case did ChatGPT create such a densely meaningful sentence wholly from the training data.)

Now, this isn’t to say that a master of their craft will always produce art as “densely meaningful” as this. While an artist can create a work that is entirely devoid of “filler”, where each and every detail in the final work is chosen to have maximal creativity and authorial intent, there are multiple compelling reasons why they might choose not to. An artist working against a deadline or a budget may not consider it wise to put the maximum attention to detail into every aspect of the project. For projects beyond a certain scope, it’s simply not possible for a single creative vision to dictate every detail. In those cases, even a master artist might outsource some of the labor to an autonomous system that can follow their design goals and directions.

And this is where the current working relationships that power the art industry will be disrupted by generative AI tooling. Because highly skilled and organized artists working on large-scale projects already outsource their labor to “autonomous systems”. But until now, those systems were called “other people.”

The exact name for these people differs depending on the details. Some of them are apprentices helping to implement their teacher’s vision. Some of them are employed by studios, working to strict style guides. But they are united by their job description: to provide labor and artistic skill in exchange for pay and a potential path toward career advancement. It’s not a position that allows them to exercise creative control. It’s a job remarkably similar to the job of designing “filler” art for offices and model homes.

Consider Dale Chihuly. Chihuly is an artist known for his impressive, large-scale blown-glass sculptures, and he’s still active today. But Chihuly has not actually operated a glass blower since 1979, when he dislocated his shoulder. He now designs his sculptures and directs their construction, but the physical labor is outsourced to employees at his studio. He is still undeniably an artist: the fact that he does not physically realize his creations himself does not undermine his creative vision. This is true regardless of whether he blows the glass himself, hires other artists to do it, or relies on some yet-to-be-invented glass blowing automation tool. Such a tool would help Chihuly, but it would also create changes in the industry’s working relationships that would pose difficulties for the rising artists who would otherwise be employed by him.

This is the impact of every form of automation, and generative AI is no exception. It can substitute for human labor but not human creativity; but as it turns out, lots of artists are employed to provide the former but not the latter. I expect to see many of these jobs replaced with automation in the near future. Studios will still hire artist employees, but fewer of them, with the job of guiding generative tooling and overseeing / cleaning up the results. As I talked about last time, this job of overseeing an AI is still a job that requires artistic skill to do well. Artists aren’t going to be replaced by non-artists. But there will be fewer job positions for artists available. And worse, because these positions were used as traditional avenues of networking and advancement, those advancement opportunities will be diminished as well.

All hope is not lost: the eternally-online nature of our generation has created new, nontraditional means for artists to network, advertise, and be discovered. Artists today can find an audience on social media, and fund their craft through not just through direct sales, but through crowdfunding and taking commissions from fans. But traditional employment opportunities are a stable, reliable way to make an income from artistic skill while advancing your craft and career.Gaining visibility on online art platforms is risky and harrowing in comparison, to say the least.

And even though the highest quality AI generated art will be created by already skilled artists, the impact of the oncoming glut of low-effort, low-cost creations can’t be ignored. Because while these creations won’t compete on quality, they will compete on cost. And in any market where art is undervalued (which is to say, any market; just ask a freelance artist what their hourly rate is), artists will need to find a way to compete with free. Which can be done, and will be done… but not everyone will be able to do it, purely due to the fact that artists aren’t just competing with low-cost alternatives, but they’re also competing with each other.

So what are these artists to do? Even if the threat posed to their livelihood is no different than the threats posed by any other form of automation, even if it’s a threat created by the market and changes to its existing opportunities and relationships (as opposed to being caused directly by the technology)… it’s still a real threat. Imagine a truck driver being replaced by a self-driving truck, or an overworked vfx artist working on the latest Marvel movie, trying to not be outdone by AI-generated special effects. The solution can’t be to say, “We could replace your job with automation. We don’t have to make you suffer this labor of indignity, but we will, and you’ll thank us for it, because it keeps you fed.” That’s inhumane. It’s a broken window fallacy used to justify unnecessary labor. But the solution also can’t be to cut these people loose with no advancement opportunities. They’re in the business because they’re either very passionate or have no other options, and cutting those jobs won’t make them suddenly have other options.

The problem isn’t in the tools we use, it’s more systemic than that. And systemic problems require systemic solutions.

Man, it just keeps coming back to the fact that all art exists in a marketplace, doesn’t it? All of the threats posed by generative AI are really just the negative externalities we see anytime automation is added to a marketplace. Which isn’t to say that they aren’t serious, because they are. But once again, it seems that the best thing we can do is challenge the system that creates these incentives in the first place. Create a path for artists and other laborers to secure their livelihoods outside of the free market and maybe then it won’t matter whether we have generative AI tools or not.

Because until we do that, we’re never going to escape this.

Mizu Network Protocol, a Primer - How to efficiently pull updates from the Mizu network by using Prolly Trees

2023-02-23T00:00:00+00:00

(Mizu is my attempt to build a peer-to-peer network protocol for decentralized applications. It is not a blockchain. This blog provides insight into the design process.)

Mizu can be thought of as having three main components, working in tandem:

A local database, which is a collection of content-addressed records which contain metadata on how the content can be rendered to the user and interacted with.
User interface tools for interacting with the database via generated web content and interactive elements that create additional transactions, which add one or more records to the database.
A network layer that allows nodes to request and receive records from other nodes, allowing each database instance to serve as a part of a distributed hash table of records.

Networking efficiently can be tricky: when a requesting node is receiving data from a providing node, both nodes would prefer that the provider not resend any data that the requester already has in its database. Ideally, the amount of data transmitted should scale with the difference between the two databases, not with the size of the databases. Synchronizing two large databases should still be fast if the differences between them are minimal.

In order to accomplish this, the nodes must be able to identify which parts of the database are already the same between both nodes, and which parts differ, without either machine having access to the other’s database.

At first glance, this seems impossible. How can the providing node determine whether or not the requesting node already has a record unless one sends the other its complete list of records?

Fortunately, there’s a powerful tool that’s perfectly situated for the task: Merkle trees.

Merkle Trees

Even if you’ve never heard of them before, you’ve probably used them. Git is built on Merkle trees. BitTorrent magnet links can be considered Merkle trees.

The idea behind Merkle trees is simple, and can be done whenever you have hierarchical data in a tree-like structure. Creating a Merkle tree from your data has three steps:

Each node in your tree is assigned a cryptographic hash of its contents, such that two nodes have the same hash if and only if their contents (their data, their children, their children’s children, etc) are equal.
Each node is stored in a hash table, with its content hash as the hash table key.
Instead of each parent node holding a pointer to its children, each parent node stores the content hash of its children. Obtaining the children from the parent thus requires a lookup into a hash table.

A Mizu node creates a Merkle tree for each topic that it may need to query the network about. This tree serves as an index and contains every database record that is related to that topic. (For example, a topic might be all blog posts by a given author.) Then, when a requesting node asks for updates from a providing note, it becomes trivial to detect if both nodes already have the exact same set of records: the nodes can share the content hash for the root of the tree: if they match, then both nodes are up to date with each other.

But what if they don’t match? There’s another possible case: that even though the root hashes don’t match, one node already contains the other node’s root hash in their hash table. This would mean that one node’s index is a superset of the other’s, and that note can easily compute each record that the other node is missing.

In all other cases, the only thing that the nodes learn is that their set of records are not exactly the same. The smaller of the two sets is obviously missing records from the larger, but is the reverse true as well? Simply looking at the root hash can’t tell us that. The nodes will have to share more information, including the content hashes of the root node’s children, and potentially the children’s children, and so on recursively, stopping only when they encounter a familiar content hash (or the leaves of the graph.) By doing this, only the parts of the graph that have changed are visited.

This is a rough description of how Git pulls work, and how Mizu requests work. But the devil is in the details, because not all Merkle trees are created equal. As the depth of the tree grows, the number of round trips / hash table lookups required to read the whole thing increases. On the flip side, you could have an extremely shallow Merkle tree with only a single root and leaves: but if you’re comparing two such trees and the roots don’t match, you now have no other option but to compare every leaf in turn, losing all the benefits of using a Merkle tree.

There’s other considerations as well: you get much better performance comparing two Merkle trees if all of the differences are isolated in one part of the tree. In the worst case where the differences are uniformly spread out among the leaves, the time to compare scales linearly with the size of the trees.

And there’s one final pernicious thorn that we have to contend with. In Mizu, not every node is going to receive every database record in the same order. If we’re not careful with how these records are processed and stored, then two nodes who contain the same set of records may end up with a different tree structure, which will have a different content hash. Comparing two databases like this could end up with the worst case performance every time, even when the databases contain the exact same records and there’s no actual work to be done. We need “history independence.” That is, two databases which contain the same set of records must produce identical trees with identical content hashes, regardless of the order in which those records were added. This isn’t hard to do (you could always just sort all the records lexicographically)… but it is hard to do while also keeping the database usable (in a format where the user can query it), and it’s also hard to do while minimizing how frequently we invalidate and recalculate content hashes.

Clearly, just using Merkle trees is not a complete solution. The way that data is structured in the Merkle tree matters hugely. There are a lot of different constraints, and if we had to design a solution from scratch, we’d be in trouble. Fortunately, there’s a specific type of Merkle tree that solves nearly all these problems. It’s history-independent, so all trees storing the same data will have the same structure (and the same root hash). It’s a drop-in replacement for index trees used in actual databases. Insertions into the tree only invalidate a number of content hashes approximately equal to the tree depth. The average number of children per-node is configurable, and it’s self-balancing.

Prolly trees come to save the day. Without them, Mizu would be horrifically inefficient.

Prolly Trees

Prolly trees were invented by the Noms project to achieve a very similar goal to Mizu: a decentralized, syncable, queryable database. Although noms is no longer under active development, it lives on through Dolt, a version-controlled SQL database with git-like commits and push-and-pull semantics.

The exact mechanisms by which Prolly trees achieve these properties is a bit beyond the scope of this writeup. It’s also been covered in much more detail (and with diagrams!) by both of these prior projects. The simple summary is that Prolly trees are Merkle trees that can store a set of key-value pairs (note: not to be confused with how the content hashes themselves are used as keys in a hash table), and they work by sorting the keys and then using a rolling hash on the key-value pairs in order to deterministically place boundaries that dictate the structure of the resulting Merkle tree. If you’re interested in a deeper dive, I recommend the Dolt docs on Prolly trees, or the Noms intro file.

The important thing is that now, for a given queryable topic, a Mizu node can create a Prolly tree which contains a content hash of each database record related to that topic. This allows two nodes communicating over the network to efficiently compute the difference between their databases and avoid sending records that the recipient already has.

Imposing a Total Ordering on Records

An astute reader might notice that I said earlier that Prolly trees solve nearly all of the problems faced by Mizu. In particular, simply using Prolly trees won’t save us from the performance problem that occurs when diffs are uniformly distributed through the keyspace (we really want new keys to be clustered to one part of the tree.) However, I also never specified that the keys used in the Prolly trees have to be the same keys used in our database. It’s nice if they are, because it means that we could query the tree like we query the database. But if our main motivation for using Prolly trees is purely to assign a content hash to a set of objects and allow for fast pulling of updates to this set… then the tree keys can be whatever we want them to be. We just need to pick a key where newer records are more likely to be compared greater than older records: this will ensure that newer records bunch up on the right side of the tree, while the left side of the tree is more “set in stone.”

(I say key here, but given that we’re using the prolly tree to implement a set, not a map, the records being stored are themselves the keys. So when I talk about choosing a key, what I’m really choosing is “a value to be prepended to the record, to influence their sorting order.” This value can be the same for multiple records, in which case those records will be sorted according to their natural lexicographic order. It removes the ability to look up whether a specific record is in the tree unless we know the extra value that we prepended, but for our purposes, that’s okay.)

This part of the protocol isn’t set in stone yet, but I have two ideas.

Idea 1: Timestamps

Mizu does not rely on timestamps, because reasoning about timestamps has to account for the fact that not every client is synchronized to the same clock, and since timestamps on messages are easily forged, there hasn’t been any real benefit to using them before now anyway. But, assuming that nodes attach a timestamp to their transactions and these timestamps are honest, it becomes an easy way to sort records so that newly added records are all at the edge of the Prolly tree. Even if nodes use incorrect timestamps, the worst outcome is that queries that contain these records will have slightly worse performance, and this bad behavior can easily be detected. Nodes could attempt to prevent records with bad timestamps from propagating through the network by rejecting records whose timestamps are outside of an expected range. (Timestamps in the future are obviously wrong, and a node may assume that it already has all records that date from well before the last time the query was run.)

A similar option is to use a non-decreasing nonce as the key: a user node tracks the highest-valued key they’ve processed, and when they publish a new transaction, they use a different nonce value for each new record, each of which is higher than the highest previously noted value. This value doesn’t need to correspond to any real-world timestamp, provided that it’s higher than all values observed in the past.

Idea 2: Topological Order of Transactions

What if, when a client publishes a transaction to the Mizu network, we capture the current state of the application, and use that (or a content hash of that state) as the key? Suppose that we take the hash at the head of one or more prolly trees (and if we used more than one content hash, making an object out of those hashes and then hashing that) and that becomes our key? In this case, the ordering function isn’t a simple lexicographic ordering of these keys, but a topological ordering of the keys, such that if content hash A points to an object which contains another content hash B (directly or transitively), then B comes before A in the ordering.

The hash table itself produces a partial ordering of all the content hashes: topological sorting would extend that partial order into a total order. However, care must be taken so that this ordering is stable: if content hashes C and D are not ordered in the partial ordering, then this extension should assign to them the same total ordering regardless of what other hashes are in the hash table.

If successful, this approach wouldn’t rely on users to play nice the way that option 1 does; normal Mizu use would automatically create a total ordering on transactions. But it’s not without its difficulties: the ordering algorithm is necessarily more complicated than a simple sorting of timestamps. It also requires publishers to divulge which records have already been processed by their nodes, which could be, in theory a privacy issue, depending on the application.

Conclusion

No project is an island. Mizu is built extensively on research done by those who have come before. It uses the json-rql query language, created by m-ld to run queries on schemaless data. It uses libp2p to connect its clients and ipld as its data model, both of which were created by Protocol Labs. And now, it uses prolly trees, which are a source of ongoing research and development at Dolthub.

To the companies who develop and maintain each of these projects: Mizu only exists because of you. It still has a long way to go, but it’s built on a firm foundation. I’m excited to see where this journey leads, and I hope you are too.

(Also, if you work for any of these companies, and you like what you see and think I would be an asset to your team and want to hire me, shoot me a line at the.solipsis.project@gmail.com!)

Decomposition (Or, What do AI art, Unity games, and Toupées all have in common?)

2023-02-15T00:00:00+00:00

(This is the third in a series of posts exploring the ramifications of generative AI.)

(Note: This article was edited since it was posted. Since the site is backed by a git repo, you can see the entire history of the article here)

In the wake of Stable Diffusion, a freelance artist friend of mine jokingly told me: “No one will ever need to commission me anymore, so long as they can clearly and unambiguously describe what they want in a prompt… so on second thought, I’m safe.” It was meant as a joke, a way of making fun of clients that didn’t know how to make a meaningful request… but in doing so, my friend described a very real skill that artists have, that non-artists typically lack: the skill of decomposition.

Decomposition is the ability to take an idea and break it down into its constituent parts, with enough specificity that (you or someone else) could follow your instructions and implement your creative vision.

Good decomposition often requires domain specific knowledge: for instance, decomposing a visual work requires an understanding of perspective, posing, color theory, and negative space. A commissioner who doesn’t understand these domains will have trouble implementing their idea themselves, and will also have trouble conveying their idea to someone who can implement it.

When a client isn’t able to decompose their ideas, the artist has to make assumptions. As a result, the final piece can deviate from the commissioner’s mental image of the piece. The artist may offer revisions, which can improve the fidelity of the output at the cost of putting an additional burden on the artist. The revision process helps because the commissioner is able to use the prior revisions as a comparison, identifying the ways that the draft doesn’t match their mental model, and refining their request. This iterative process can compensate for the fact that they lack the vocabulary and domain knowledge to concisely describe their vision: they lack decomposition, and so the process is longer and more burdensome. The artist must invest their own creative effort in order to pick up the slack.

This is remarkably similar to the process of using generative AI. The most common public perception of the process is that a user submits a single prompt, and publishes the results with no refinement. However, often the process is more iterative, with the prompt being refined over multiple generations, and the user exercising editorial control to weed out results that don’t match their creative vision. Many tools allow a previous output to be fed back into a new query, with additional instruction. In that way, the results gradually become shaped by the user’s creative intent. But the highest fidelity of the results, and the amount of effort required to achieve that fidelity, are both dictated by the user’s ability to describe their objective in a way that the AI tooling can generate it. This is, it tests the user’s ability to decompose. The better the user is at articulating the elements of their concept (the better the user is at decomposition), the faster this refinement process can take.

In summary, AI generated content can only capture the user’s intent if the user is able to express that intent. And this is an ability that will always be stronger in more experienced artists.

There is also one crucial difference between this iterative process with an AI versus a human artist: if the user cannot unambiguously describe their intent, there’s little the AI can do to compensate. There’s no human artist to draw from their own expertise to account for the user’s lack of it.

Overall, this tells us two things about using AI generators to create art:

Using an AI generator is “effortless” only when the user doesn’t have a particular mental image or authorial intent that they’re trying to convey. Any sufficiently meaningful content produced with generative AI tooling still requires effort and skill from the user (although less effort and skill than would be required with non-AI tooling, perhaps substantially so.)
Despite the fact that using an AI image generator does not require one to draw art in the conventional sense, there is still a direct relationship between the user’s artistic skill and the amount of labor required to produce a satisfactory work: the more artistically fluent the user, the less labor required, and the higher quality output.

The first point is important because the public perception has a tendency to cast all AI generated content as the “effortless” variety. This is because of the Toupée Fallacy: poor-quality AI generated art is more obviously AI generated. It is also, given the ease of creating it, more plentiful than talent and labor driven AI art. It’s reminiscent of the PR disaster that was Unity requiring Personal Tier users (and only Personal Tier users) to display the Unity logo in games using the engine, creating an association between the logo and a lack of quality. When low-effort content is most easily associated with your tool, your tool gains a reputation for low-effort content, even if more artistically merited content also exists.

This distinction matters because perception influences how we interact with the challenges posed by generative AI. Most hosting platforms that I’ve seen address it have taken the action of preemptively cutting off the firehouse of low-effort content by banning all content created using AI generated tools. A few adopted a more cautious approach: one site, for instance, required all content that was created (in part or in whole) by AI to be appropriately tagged, and required the publisher to identify the tool used, as well as all prompts given to it.

While the intention of such a policy was to assuage fears about low-effort AI art “displacing” high-effort content, I suspect that it will actually have the exact opposite effect. The posed requirements (disclosing every input to the AI tool) is trivial for anything that was produced by a single, unrefined prompt. But what about pieces that were developed over several laborious generations, where the input to each round is built on a previous output, where the user carefully and delicately composited multiple outputs into a single piece, then continued to use AI tooling to further modify it? How should the totality of these inputs be disclosed? What happens if the creator didn’t keep detailed enough notes? Policies like this, while well-intentioned, effectively create a ban on high-effort works, while letting low-effort works through.

Even as the debate continues around whether generative AI can help produce high-quality original works (and it can), we should be thinking clearly about the impact that community policies will have on both desired activity (high-quality works) and undesired activity (low-effort AI spam), and choosing policies that encourage the former while discouraging the latter.

If there’s a silver lining here, it’s that hard work and human skill is valued, even in places where we know with absolute certainty that automation can do it better. Humanity didn’t stop caring about professional chess as soon as Deep Blue came out. We didn’t stop admiring realistic paintings after the invention of the camera. And we’re not going to stop valuing artistry as a skill just because tooling now exists to autmatically and cheaply produce low-value alternatives.

But that doesn’t mean that the next ten years won’t be incredibly disruptive for professional artists. Everything I just said about requiring artistic skill in order to create something that conveys artistic intent is that “low-effort” content is undesired. If instead the user has only a small set of criteria and isn’t necessarily concerned with the actual value of the resulting piece, AI is more than up to the task. The gaps in the prompt will get filled with a perfectly generic simulacrum of the medium… but depending on the requirements, a user may decide this is acceptable. AI art created by unskilled users exists, it’s plentiful, and the fears about it competing with traditional art are real and founded. But understanding the consequences of that and how to handle it is a venture in itself, and one that we’ll save for next time.

On Volunteer Fire Departments - Part 3: “Find the Meaning of VFD” (Apache PLC4X)

2023-02-01T00:00:00+00:00

(This post was originally written in January 2022. It might seem a bit dated now, but just wait until the next time Open Source Discourse rears its ugly head; it will seem prescient then.)

January 2022 was a firestorm of high-profile pronouncements by open-source devs painting a grim future for the ecosystem. First, in part one of this trilogy, Volkan Yazici spoke out about the stressful working conditions and rough treatment of the log4j developers as they patched a critical 0-day. Then in part two, Marak Squires defaced several repositories that he controlled in order to make a statement.

But the most heartbreaking story happened a couple of days after, when Christofer Dutz, the creator of Apache PLC4X, announced that he would no longer provide free community support for the tool, and that unless he finds a new source of funding, he’ll be shutting down his business entirely.

He makes it clear that this was not a decision made hastily or enthusiastically. Although the discourse surrounding the open source ecosystem was filled with talk of exploitation, Dutz carefully avoids using such language, even as he expresses frustration with enterprise users who expected free support. He’s not out to punish anyone; he’s merely acknowledging that there is no practical path forward without adjusting either his funding or his community contributions.

Like Yazici, he’s burned out by personal sacrifices that mostly served to enrich enterprises that benefit massively from open-source projects without giving back to it. Like Merek, he’s exercising his right to no longer participate in a system that no longer respects him.

I don’t have much to say about his decision. Dutz is right; he’s not a slave to the open source community. There’s no clause in the Apache 2.0 license that obligates him to lend his services to anyone, nor should there be. He made it clear in his post that the PLC4X project is bigger than him, and that even if he stops offering support or contributing to it at all, the project and the community will continue to exist.

He makes a compelling case that, at least for him, the status quo is not sustainable. He’s not the only one to come to that conclusion, but his own documented experience lends a credence to it, moreso than anything else that came out of the month-long discourse.

I find the unique crowd-funding approach he talks about in his post intriguing, and hope it bears fruit and can pave the way forward for more projects. If the open source needs to reconsider how its gets funding, maybe this will be it. Or maybe it won’t. Overall, crowdfunding seems to be a mixed bag: it’s sustainable only for a lucky few. And if more open-source projects move to a crowdfunding model, then they’ll all be competing with each other for the same slice of disposable income and grant money: even if it works for Dutz, it could turn out to not scale. But only time will tell for certain.

I hope that his ultimatum serves as a warning and that he gets the funding he needs. But if he does, I think we also need to remind ourselves that this is not a solution, because it never should have gotten to this point. “Walking out if the big companies don’t pony up” isn’t a solution, it’s the regrettable reality of a world where critical public resources are left unfunded. It reminds me of the “feel-good” stories about workers donating their sick days so that a coworker can take time off for surgery, or a kid running a bake sale to pay off classmate’s lunch debts. Solving a crisis for one person is a miniscule comfort if we don’t deal with the systems that allowed such crises to happen in the first place.

To be 100%, explicitly clear: this is not a knock against Dutz. It sounds like he sincerely cares about his projects and his community, and now he’s at his wits’ end. Dutz’s testimony underscores the importance of supporting devs, specifically because of the community harms that can come to pass when they feel like they can’t contribute anymore.

My point is to caution against viewing this as a walkout or an otherwise noble act. It’s an outcome that sucks for everyone because we don’t have the systems in place to properly support developers.

So how do we fix it? How do we keep open source projects funded and stop developers from burning out? I don’t think this problem is going away until we have governments that treat open source as public infrastructure and are willing to fund it via grants, etc. I’ll never stop wondering how much good-for-society-but-not-easily-monetizable work is being locked up by a system that keeps people in a perpetual state of economic insecurity.

But big sweeping changes to economic incentives won’t happen overnight, and aren’t easily actionable. So what do we do until then? What’s the lesson from this whole mess?

I’d say it’s three things. Three pieces of advice.

Take care of yourself. You’re not helping anyone if you burn out or if you burn through your savings attempting to live an open-source bohemian lifestyle. Open-source code often comes with no liability, and you shouldn’t feel like you owe anything to your users.
That said, consider what communities you care about, and the effect your actions have on those communities. Who gets helped? Who gets hurt? In a world where everyone is competing for limited resources, how does your decisions influence who gets a bigger slice of the pie?
For the love of God, think carefully about what license is best for your code. Understand that your code will be used by people who do not share your values, who will likely find ways to use your code in ways you could not anticipate and could not condone. If you’re not comfortable with people profiting from your code without contributing in return, don’t choose a license that will let them do that.

These lessons aren’t much, but they’ll have to do.

On Volunteer Fire Departments - Part 2: “Look At What You Made Me Do” (faker.js)

2023-01-19T00:00:00+00:00

(This post was originally written in January 2022. It might seem a bit dated now, but just wait until the next time Open Source Discourse rears its ugly head; it will seem prescient then.)

Last time I talked about Volkan Yazici, one of the developers of log4j, and his selfless response to a critical security bug that threatened users of many commercial products.

The event kicked off a flurry of discourse about how open source projects ought to be funded, and what these projects are owed by their users.

That discourse might have petered out, if not for Marak Squires, the creator of the open source project faker.js. A week after the log4j vulnerability was exposed, Marak sabotaged his own project by deliberately introducing a change that would cause it to fail on startup. He then claimed to be unable to fix it, while using his ownership of the project to prevent anyone else from fixing it. He would later go on to obliterate the repository on GitHub, and edit pull requests designed to point users to forks of the project to instead point to a /r/conspiracy post about Arron Swartz. This was, ostensibly, an act of protest against how companies “take advantage” of open source projects without contributing monetarily back to them. As a result, he was banned from GitHub, where he took to Twitter to assert his right to torch repositories he owned, should he choose to do so.

Given the timing, his behavior was clearly inspired by Yazici. And yet, reception to the stunt was significantly more mixed. People were pissed, obviously. Others sympathized with Marak’s frustrations and leapt in to defend him. Some took a middle road to assert that, “yeah, it sucks, but this was his project, others shouldn’t feel entitled to it, and he can deface it if he wants to.” I find this argument the most intriguing. I’m also marginally more sympathetic to it than the others, because it actually acknowledges the complexity of the issue and tries to reason about his actions as they fit into some value framework (in this case, the idea of “project ownership”). But it’s a value framework that I feel fundamentally misrepresents open-source.

Open-source, at its core, is a voluntary relinquishment of some or all of the concept of “ownership” of a project. Ownership, as an absolute right, is often seen as including “the exclusive right to destroy something or deny others its use.” An open-source license waives that right, either conditionally or unconditionally. Giving up that ownership means reduced responsibility, but also reduced control.

faker.js was published under the MIT license. The MIT license, like log4j’s Apache license, explicitly permits commercial use of the code, and also grants blanket permission to republish and modify the code. Once I publish code under this license, I can never again be its sole steward, because anyone else can fork it. Now, there’s nothing in it that waives my right to deliberately make the licensed code harder to access, or introduce bugs, or try to prevent people from finding the licensed code. But the spirit of MIT license is to allow others to preserve the licenced work by reuploading it, and permission to reupload a creative work is completely useless if no functioning copies of that work remain.

If I create something, and bequeath it to the world under an open-source license, I’m not under any obligation to help people use it or preserve it; no one is entitled to that from me. I can wash my hands of it specifically because it exists outside of me and does not need me. But if I commit something to open source and then actively attempt to make it more difficult to use, I should be rightfully called out for that. No one should be defending me with the argument that I have the right to cause misery to the users of a project simply because it belongs to me. The project doesn’t belong to me in the conventional sense; that’s the whole point.

There’s also the fact that Marak tagged the malicious revision with the “latest” tag, which meant that any users who used a package manager to update their software would be updated to the malicious version. This was an act that had nothing to do with any intellectual property claims to the underlying code. The argument of “It’s his project, he can do what he wants” ends as soon as he starts interfering with the operation of package managers and their users. These package managers are under no obligation to host his malicious content.

As an analogy: Just because I sell engine parts under a license that says “no liability”, that doesn’t mean I can just deliberately trash your engine or force a store to carry broken parts. That’s not how it works, legally or ethically. It’s not in the letter or the spirit of the license. (This is not legal advice, and I am not a lawyer.)

Marak doesn’t owe the open source community anything, just as the community doesn’t owe him anything. But his actions here are an affront to the same values that the open-source community claims to uphold.

Yazici found himself in a crisis, took on a responsibility to help his community, and then spoke out about the conditions that put him in an unenviable situation. Marak created a crisis, and then invoked ownership rights to justify harming members of his own community. These are not the same.

Marak framed his actions as an act of protest. And yes, a protest needs to be inconvenient for the masses, or else it’s merely ignored. But his behavior wasn’t just inconvenient; it actively harmed the people that he claimed to be trying to protect, while leaving the masses mostly unaffected. If it becomes necessary for project maintainers to plan for and handle the event that one of their dependencies might just decide to sabotage their own projects (and perhaps this is already a concern that any decently sized project needs to handle) it’s other third party and independent developers who are hurt the most by this, since the larger fortune 500 companies are going to be better able to allocate resources to handle such a disruption, or more likely to already be using their own forks of the project and be completely unaffected. And since competing for user’s attention and funding is a zero sum game, that means that roadblocks like this ultimately serve to help fortune 500 companies beat out their competition.

I once had an industry job maintaining a company-internal fork of an open source project. I was ordered not to contribute my changes back to the original project, for a variety of reasons: partly because we often introduced extensions to the DSL to suit our own use cases, or added features that, if pushed upstream, could create a maintenance burden for the original project. But also because, even though the company made every effort to ensure compliance with the project’s license, we were worried that even the appearance of noncompliance could open us up to time-consuming (if frivolous) litigation. Over time, our internal fork diverged to the point that it was effectively a different product uniquely suited to our needs (and at this point we also stopped pulling updates from their repo as well). My understanding was that this was the standard industry practice for this particular tool… provided that you were a big enough company to afford it.

The project owner’s income came from offering upgraded licenses and dedicated support. I can’t imagine they were thrilled that they weren’t making any money from us, or any of the other major industry players.

If something happened to the official code repo, we would have been completely unaffected by it. But this was only because we had the engineers and the resources to maintain our own fork. I can’t say the same for our smaller competition. The smaller corporations and the nonprofits and the hobbyists depended on the official repo in a way that we didn’t. If something happened to that repo, it would have given us an incredible competitive advantage. So even though we were benefiting from the project without giving back to it, its continued existence played an important role in mitigating our dominance in the field. Our (ab)use of the project didn’t stop it from being a source for good.

That’s not the most intuitive thing, so I’m going to emphasize it: just because we were a big company taking advantage of an open-source tool, that didn’t mean that the tools’ existence gave us a competitive advantage. If anything, the tool was an equalizer, and ending its support or development would have cemented our market position, not eroded it.

Returning to the volunteer firefighter comparison from the previous post, the solution to big players being reckless with fire isn’t to say “big buildings need to pay us or else we won’t fight fires anymore.” Because those big buildings are the ones who can afford their own dedicated firefighters. If the volunteers quit, it’s not the big buildings that lose out. It’s all the little ones.

The worst thing we could do would be to return to the days of for-profit firefighters. But to prevent that, we need to make sure that the volunteers stick around, that the community continues to be built around the values of distributing code not to make a profit, but because a rising tide lifts all boats. And that requires making sure that contributors have their needs met.

Supporting open-source development is essential for the future of the open web, and we should be exploring all our options. But I can’t in good conscience support “burning it all down” as the solution.

But this still doesn’t suggest a solution for struggling open source developers. Without a clear way to fund critical infrastructure, it makes you want to throw in the towel.

Next week we look at Christofer Dutz, who considered doing just that.

On Volunteer Fire Departments - Part 1: “With Great Power” (log4j)

2023-01-11T00:00:00+00:00

(This post was originally written in January 2022. It might seem a bit dated now, but just wait until the next time Open Source Discourse rears its ugly head; it will seem prescient then.)

My condolences go out to the log4j developers, whom I’m sure have had a busy month. I’m not going to recap the finer points of what happened, because that’s been done to death already. But the very condensed story is that lots of projects, including many important projects by for-profit corporations, depend on log4j, and then it turned out that log4j had a critical vulnerability that compromised all these projects, and that fixing the vulnerability turned out to be a major undertaking.

Being an open source developer during a zero-day is like being a volunteer firefighter. You’re underappreciated and underfunded. When things go right, no one notices you. When things go wrong, people demand that you fix it. It’s a stressful, thankless job that doesn’t come with any guarantee of pay or respect, even though anyone willing to undertake such stress and such risks for the sake of a public good certainly deserves both. It’s a position motivated by the desire to help your community, and it comes with freeloaders who profit from the service without paying for it.

The difference is, we tend not to call people who depend on volunteer fire departments “freeloaders.”

log4j was released under an Apache License 2.0, which allows every company who used log4j to do so without requiring payment, or any obligation to give back to the open-source community. It’s not entirely for free however; in return, these companies release log4j of any liability stemming from the use of their library… liability which, at the moment there seems to be a rather lot of.

The log4j developers were not liable for what happened. I’m sure they knew that. Yet, they knew the potential for collateral damage to innocent users that this vulnerability held, recognized that they were in a unique position to fix it, and took it upon themselves to patch the vulnerability and help users mitigate the damage. One of the developers, Volkan Yazici, voluntarily worked 22 hour shifts to help users mitigate the damage. (https://www.technologyreview.com/2021/12/17/1042692/log4j-internet-open-source-hacking/ ) And then, feeling burned out and frustrated, he went to vent on Twitter. (https://twitter.com/yazicivo/status/1469349956880408583?lang=en)

This post would go on to fuel an incredible amount of discourse about the relationship between big tech companies and open source projects. About what is owed to these developers, and by whom.

Yazici’s position deserves a lot of sympathy, not just in spite of the fact that he volunteered, but because of the fact that he volunteered. We often encounter situations where people are unfairly burdened by circumstances, where we have the power, but not the obligation, to relieve that burden. And when doing so puts a burden on us, we reserve the right to complain about it, even though this is the outcome we chose.

I hope that if I were in their position, I would do the same. Although if I were in their position, I would be sorely tempted to wait until one of the major companies using log4j agreed to pay a generous hourly rate for my support. The point wouldn’t be to hold these innocent users hostage until the companies pay up, but rather to acknowledge that these companies also have the power to fix this mess they created, by using the same free market that they live and die by. To remind these companies that there are costs to relying on software that has no promise of support, that if they want the guarantee of safety, they need to either take on that support burden themselves or pay someone else to. If I’m going to be donating my time and energy to patch a major vulnerability, I want to make sure that I’m bailing out the innocent people affected, not the companies that put them in peril in the first place.

But the log4j developers didn’t try to use this crisis to coax funding from corporations, because their motivation wasn’t to profit, but to help a community in crisis. It wasn’t about payment or recognition, but about creating something good and putting it into the world. This was, after all, why the project was published under such a permissive license in the first place.

A brief aside about licenses: Picking a license is important. For example, this blog is a Creative Commons By Attribution license. Is that the right license for this? Do I believe that I am entitled to attribution for my work? I’m not sure. Would attribution be nice? Certainly. If someone uses the content in this blog without giving me credit, am I going to sue them? Probably not. Lawsuits are a massive headache, and more importantly, it’s not clear how someone using my content without attribution harms me, and I’m a staunch believer that lawsuits should prove some demonstrable harm in order to be moral.

So if attribution is more of a preference than an actual practical requirement, why choose a license that requires it? Why not choose a minimal CC license and just add a bit about “if you use this, it sure would be nice to give me a shout-out”? Because I can’t predict how people will use my work once it’s been released into the world, and it’s completely possible that someone will come up with a creative use of my work that I never would have thought of and that I find objectionable. Choosing a specific license gives me the right to enforce my rights later in response to unforseen circumstances, but only if that behavior runs afoul of the license. If I went with a minimal CC license, and then someone uses my work in a way that I believe is unfair but is fully within the scope of the license, then I have every right to complain about it, but the world has every right to think I’m being rather silly for getting mad at someone for doing something I explicitly allowed them to do by choosing such a minimal license.

My point is that choosing a license is not a decision to be made lightly. I’m a huge proponent of open licensing, but I would strongly urge anyone considering publishing under such a license to make sure that they understand the ramifications of the license they choose, because these licenses are non-revocable.

log4j was published under a license that explicitly allows large companies to profit off of the code, without requiring any contribution in return. It’s possible that the devs fully anticipated that this would happen. It’s also possible that they didn’t. But the choice of license gives us insight into the project’s values and intent.

As far as I saw, no one directly involved with log4j was saying anything about feeling obligated to make the bigger users pony up. This was done entirely by the community on their behalf. The developers recognized that this was a situation that they put themselves in voluntarily, because they recognized that they were uniquely qualified to prevent the suffering of a lot of innocent bystanders. And they deserve to get credit for it. I’d even say that they deserve funding for providing such an important public service. But where that funding ought to come from is a nuanced question, and it’s not at all clear that the answer is, “from the people who used our code in accordance with the license that it was published under.”

But this isn’t the end of the story. Yazici’s plight didn’t just lead to discourse and debate. Clearly, it wouldn’t be enough to just react to fires.

It was a matter of time until one person decided to start one.

Next week we talk about faker.js, and what happens when the fire comes from inside the house.

Tears of a Robot Clown

2023-01-05T00:00:00+00:00

(This is the second in a series of posts exploring the ramifications of generative AI.)

Not only are machine learning models a genie that can’t be put back in the bottle (for better or for worse), but with the release of ChatGPT it’s clear that the technology is improving faster than most people were anticipating.

No, we don’t have “self-aware AI” yet, far from it. But what we do have is truly impressive. Which makes it all the most important that we understand exactly what it is that we do have, what it can do, and what it can’t.

I’m not going to touch on the issue of “is AI generated art merely plagiarizing elements of the training set,” primarily because there’s nothing I can meaningfully add to the debate. We know that these models can reproduce high fidelity copies of popular low-entropy works (just ask ChatGPT to recite The Raven). At the end of the day, people who feel anxious about the future of their careers or feel violated by the use of their art in training data will insist that AI models must plagiarize, while people who understand how the technology works insist that AI models don’t need to plagiarize to produce the outputs we observe.

Neither of these groups are going to change each other’s minds, and this is all that I’m going to say about them.

What I will say is that in my own experience playing around with ChatGPT, I’ve been blown away by its ability to generate text content that is, as far as I can tell, entirely original. And not just original, but funny.

Specifically, I asked ChatGPT to write jokes. I gave it joke setups that I invented on the spot, and asked it to create the punchline, and explain the joke to me. Most of the “jokes” were, to put it bluntly, not funny. Some barely even qualified as wordplay. But there were a couple of gems that got a genuine laugh out of me. My favorites were:

Q: What is Frodo Baggins’ favorite sport?
A: Ring Toss.

Q: How many birds does it take to change a lightbulb?
A: None, they just sit in the dark and tweet about it.

Q: What is Oedipus’s favorite mixed drink?
A: A mom-osa.

Again, to the best of my knowledge, these are entirely original jokes. I searched but was unable to find any evidence of these jokes being told online. (If anyone reading this has heard any of these jokes before, or better yet, knows where I can find a written record of any of them, please let me know.)

So what gives? Can computers be funny now? If the humor wasn’t stolen from other writers, where did it come from? Presenting these jokes on their own suggests that the ChatGPT is funnier than I could ever dream of being.

But presenting these jokes on their own removes very important context that perhaps might elucidate what’s actually going on.

For starters, I edited the jokes to make them land better. The original Ring Toss joke asked what Frodo’s favorite Olympic sport was. I removed the world Olympic because Ring Toss is not an olympic sport. (I wonder if ChatGPT latched onto a connection between “Olympic” and “Ring” and was aiming for some double-wordplay that didn’t land.)

I also didn’t show you any of the jokes that weren’t funny. And there were a lot of them. More than there were funny ones. I didn’t save them, and I barely remember most of them. Here’s one I do remember, because of how profoundly unfunny it was.

Q: Why did Captain Picard go to space?
A: To boldly go where no one had gone before.

I mean… I get it. I get the reference. But that’s all it is. A reference. ChatGPT explained the joke as “humorously imagining Picard taking his catch-phrase literally.” But… that’s what he does every episode. There’s no joke here.

The others followed a similar pattern: the punchline was always thematically cohesive with the setup. Usually they even had some form of double meaning or wordplay, which it then explained. The problem is that wordplay is not necessarily funny. Even in the jokes that were funny, the generated explanation merely explained the wordplay, not why the joke was funny.

So if most of the responses weren’t funny, but they did all have some kind of wordplay, then it turns out what I’d created wasn’t a joke engine, but a word-association engine. And while humor is subjective and creative, word-association is a tractable problem. In fact, it’s a tractable problem that language models are quite good at, for understandable reasons.

When I asked ChatGPT to come up with Oedipus’s favorite mixed drink, it needed to generate a response that was associated with both Oedipus, and mixed drinks. And it turns out that the phrase “mom-osa” is all over the Internet, meaning a mimosa or mimosa-variant made by or for moms. ChatGPT didn’t invent the term… but it did connect it to Oedipus. It wasn’t trying to be funny, it just identified a word that could be associated with both parts of the prompt.

What ChatGPT did was make a million monkeys bang on keyboards, narrowed the search down by eliminating the results that had no word association, and then tasked me with sifting through the noise to find out which ones made me laugh.

That last part is the most important piece. These weren’t just spat out by a machine; they were the result of an interactive process in which I was an active participant. Without a human actor evaluating and editing the output, the quality degrades dramatically. This is more true the more sophisticated the project, but we see signs of it even here, with a relatively simple prompt.

It gave me a dozen jokes, and I chose three of them. ChatGPT couldn’t have done that choosing for me, because it had no idea which jokes were actually funny. I looked at a list of generated word associations (a very computable and not-funny task), and I saw the humor that occurred by chance in a quarter of them (a very funny but not very computable task).

So where did the humor in these jokes come from?

It didn’t come from the training data, because these jokes aren’t in the training data. And I’d argue it didn’t come from ChatGPT either, because while generative AI is constantly amazing us with the new things it can do, humor is such a subjective and context-sensitive pursuit that I expect it to be one of the last things that these models will conquer.

But there’s one other part of the system: me. In separating the chuckles from the duds, the humor I was observing wasn’t inherent in the responses, but rather something I was projecting onto them. By reading, selecting, and editing the responses, I used my own labor and my own creativity to arrive at something that I thought was funny.

Now in the case of these jokes, it wasn’t very much labor, but these aren’t very great jokes either. They’re just simple wordplay with a miniscule amount of human creativity sprinkled on top.

ChatGPT’s output was a Rorshach test: ChatGPT didn’t write jokes any more than Hermann Rorschach drew pictures of my parents fighting.

It’s said that you can find every possible string of text somewhere inside pi. (This isn’t actually proven to be true, but that’s beside the point.) Does that mean that pi is the [i]source[/i] of every possible string of text? Of course not, because to find them you need to already have an idea of what it looks like. The creativity is in the effort of extracting the string. Tools like ChatGPT reduce that effort, but you’ll still get out of it only what you put in.

In a World Where You Can Make Anything, Make Kindness

2022-12-30T00:00:00+00:00

(This is the first in a series of posts exploring the ramifications of generative AI.)

I live with a foot in two worlds.

According to people in one world, generative AI tools like Stable Diffusion and ChatGPT are going to usher in a new golden age of independent creation by massively lowering the barrier of entry and labor costs of independent artists.

According to people in the other world, these same generative AI tools are going to usher in an era of exploitation and poverty for artists, whose sources of income dry up as they find themselves replaced with automation. The Disney Behemoth trudges on, dictating their vision of human culture. Only this time, the artists are removed from the equation entirely.

I think what the debates around generative AI tend to miss is that these two worlds are not contradictory; they can and will coexist. As a result, the butting heads tend to talk past each other.

Let’s break this down; for lack of a better term, let’s call the people living in these two worlds the fanatics and the skeptics.

There’s an instinct by the fanatics to cast the skeptics as worrywarts. They point out (correctly) that automation has never been the death of creativity. MIDI did not kill the orchestra. Chess bots did not kill competitive chess. They point out (again, correctly), that automation frees up labor, which can (in theory) now be spent on additional creative pursuits. They call the skeptics Luddites.

(For the unaware, the Luddites were a secret organization of textile workers who sabotaged textile machinery. Many of them were the former owners of independent workshops that had been forced out of business by larger factories. While the term has been watered down and become a pejorative for anyone who disavows modern technology, its roots are important.)

The arguments of the fanatics are not technically wrong, but they get rejected by the skeptics anyway, for a simple reason: it does not solve any of the real problems faced by the skeptics.

The comparison to Luddites is especially ironic, given that the real Luddites had a real grievance, and a real point: not that automation would destroy their industry (it didn’t), but that automation would displace many workers and remove a source of income upon which they relied. That even though automation increases the total productivity and cultural output of a society, those gains are not distributed evenly. (Who specifically would benefit from those gains would depend on the economic system, and America has never had an economic system that favors the independent laborer, if such a thing is even possible.) And that when the productivity of a job increases, fewer of those jobs are needed: people will, necessarily, be put out of work.

When people express concerns about how their livelihoods will be upended by new technology, it’s not helpful to point out that these tools will enable additional creativity in aggregate by decreasing the barrier to entry, or reduce the labor costs in art, or make it easier for artists to balance their art with another revenue stream (assuming they’re privileged enough to have one), or boost the aggregate quality of living of humanity.

These are all true… but for someone worried about their income, it’s a small comfort. Especially if those purported gains will mostly be enjoyed by someone else.

The fanatics, unable to think beyond the abstract and unable to see beyond their own face, completely miss the point. They’re not wrong, but at best they’re callously dismissive of the actual problems presented to them.

The skeptics meanwhile, facing a real sense of impending doom and economic anxiety, attempt to identify the source of their discomfort, in the hopes that naming the problem will reveal a solution. The problem, they say, is that these machine learning models are trained on copyrighted data without the permission of the owners. It must be, they say, because where else does the apparent creativity of the generated content originate? The solution, then, must then be to expand copyright law to explicitly forbid the use of unauthorized copyrighted material in training data (or perhaps even ban generative AI altogether).

The problem with this proposal is that it will actually make the (again, very real) problems introduced by generative AI worse, not better. This is because the skeptics have misidentified the actual threat. (Hint: it’s almost never the tools.)

Let’s suppose that the skeptics succeed in their goal of expanding copyright to exclude training data from fair use. What will be the consequences of such a decision? Who will suffer the most?

I can tell you who will suffer the least: large publishing companies who have already amassed a considerable degree of copyright: the very same organizations that the skeptics claim to be fighting against.

In such a world, Disney will still be able to make their own generative AI models, trained on their own massive library of content. They will implement the use of these models into their workflow, reducing the labor required to produce their immensely detailed animated films, which will require them to hire fewer artists. The great displacement of artists and creative vision from an increasingly procedurally generated culture will continue, unabated.

The only people who are hurt in such a world are independent artists who, by the skeptic’s own hand, now lack the ability to use the same tools as their larger competition.

And what about the bolder proposal: to ban all use of generative AI, regardless of the ownership of the training data (or alternatively, a proposed cap on the proportion of a project that can consist of AI generated work)? That will never happen, at least in the US. If not because of the obvious First Amendment implications, then because there is a concentrated amount of capital in Hollywood and elsewhere that has a vested interest in this not happening. The genie cannot be put back in the bottle.

There is no outcome where generative AI does not fundamentally change the art industry. (And like it or not, art is an industry, and under our current economic system where only that which is profitable is able to exist, nearly all art participates in this industry.) The art market is a zero-sum game: while new tools can boost productivity for everyone, there is ultimately a finite amount of customer time, attention, and disposable income. Any artist using the market as a source of income is competing for a slice of this pie.

The impact of generative AI on the industry is pretty clear: by reducing labor and removing barriers to entry, these technologies increase competition. Unfortunately, corporations who own the world’s capital and means of production are best poised to take advantage of this new technology and take the lion’s share of the subsequent monetary benefits… but even if they weren’t, the introduction of new competition will make the field less profitable anyway.

The losses suffered by Luddites from the invention of the textile factory was real and measurable. The fact that we today enjoy the benefits of textile automation doesn’t change that. Likewise, the losses that will be suffered by truck drivers from self driving cars will be real and measurable. And the losses that will be suffered by independent artists from generative AI will be real and measurable.

This could very well push important fields like art and culture into the realm of unprofitability. These concerns are real and valid. But the flaw isn’t in any tool used by artists or laborers, but in the framework of capitalism that these artists and laborers are forced to participate in. It’s not generative AI that’s devaluing art: it’s the market, and the fact that we have tied the worthiness of art to its market value.

The production of art in our economy is only possible when it can be profitable. But the unfortunate reality is that not every business is guaranteed to be profitable, even businesses that we consider essential for society. And when we have an economic system that says that only things that are profitable are able to exist, there’s a temptation to enact policy to keep a specific business model profitable, with the argument that doing so serves a greater good.

(That temptation is doubly present when your own well being and career also depend on preserving that business model: if you’re significantly invested in a business model, any technology that disrupts that model is now an existential threat.)

But it’s not the technology that’s the threat: it’s the social and economic relations that all art production is forced to participate in. It’s the lack of social safety nets. It’s the fact that the means of cultural production are owned by large corporations. It’s the fact that all artists must compete with each other in a market that will always be rigged in favor of larger publishers. @ckjong on Twitter does an excellent job of summing this up.

And like he says, those relations can be changed! But only if we can recognize their culpability.

At the core of being a modern artist is a conflict: Culture benefits when the barrier to participation is low: when everyone has a voice and the dominant cultural attitude isn’t dictated by a class of elites. But sellers in markets benefit when the barrier to participation is high: preventing new competition from entering the market helps maintain the value of what the seller is selling.

When art is a market, these two facts are at odds with each other. Anyone who participates in the art market as a seller (which is to say, all professional artists) is forced to grapple with this conflict.

The skeptics, forced to prioritize their own well being and unable to question the very system that they’re forced to participate in, miss the point. They’re not wrong, but being (understandably) unable to think beyond their own immediate self-preservation blinds them to the real threat.

The remedy for both fanatics and skeptics is the same: to challenge the social and economic conditions that lead to the commodification of art in the first place. The conflict, it turns out, is not fanatics vs skeptics. It’s fanatics and skeptics vs a system that says that your value is only as much as people are willing to pay for it, a system that exacerbates inequities because capital attracts capital.

Generative AI can be a great cultural boon, but only when the fruits of those labors are shared, only when the intrinsic value of art is separated from its market value, and only when art can be produced free from the corrupting and coercive hand of consumerism and wage slavery.

I think that’s something worth fighting for.

But at the very least, the next time that you get in an argument with someone about generative AI… be kind. Be patient. Be empathetic. Recognize that our positions in such debates are often derived from our lived experiences, which are different from the lived experiences of others. Recognize the role that your own financial and social situation plays in shaping your viewpoint, just as it does for them. Seek to understand, not to win.

In a world where you can make anything, make kindness.